Here's a hs_err file after a crash I had yesterday. We turned off some
things in our code without restarting and the crashes have virtually
stopped but we do still get the off one here and there where the
application has not been restarted, could be that the problem lingers
and builds up in time, w
stopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Taylan,
>
> On 3/15/2010 10:19 AM, Taylan Develioglu wrote:
> > The cause for the crashes was in our own application code, we're
> > currently investigating the exact reason.
>
>
+0100, Taylan Develioglu wrote:
> Hi Carl, thanks for the suggestion. I am going to try jvm 1.6.07
> regardless of what I said before.
>
> Funny coincidence, I tried the ibm jvm as well and ran into a similar
> issue (part of our ssl implementation uses sun specific libraries).
>
>
27;t with seemingly the same setup.)
>
> Thanks,
>
> Carl
> - Original Message -
> From: "Taylan Develioglu"
> To: "Tomcat Users List"
> Sent: Thursday, March 11, 2010 6:13 AM
> Subject: Re: jvm exits without trace
>
>
> >a differe
a different kernel did not help either...
On Thu, 2010-03-11 at 11:37 +0100, Taylan Develioglu wrote:
> Changing to JIO didn't help, the silent crashes continue.
>
> I'm changing kernel versions now.
>
> On Fri, 2010-03-05 at 10:45 +0100, Taylan Develioglu wrote:
&
Changing to JIO didn't help, the silent crashes continue.
I'm changing kernel versions now.
On Fri, 2010-03-05 at 10:45 +0100, Taylan Develioglu wrote:
> It's performing rather poorly performance wise, compared to the apr
> connector. The number of threads required to ha
k said was true.
On Tue, 2010-03-09 at 19:29 +0100, André Warnier wrote:
> Taylan Develioglu wrote:
> > Chuck, if that is true how can we explain I see only 637 busy threads on
> > a server that is serving 2172 clients ?
>
> Woaw ! can you give us your trick ?
>
> &
Chuck, if that is true how can we explain I see only 637 busy threads on
a server that is serving 2172 clients ?
If every connection requires its own thread there should be 2172
threads.
On Tue, 2010-03-09 at 16:40 +0100, Caldarale, Charles R wrote:
> > From: Taylan Develioglu [mailto:td
The switch is from APR to JIO. SSL practically doesn't get used.
Almost all pages served are jsp or java, very little static files are
served and keep-alive is on.
where peak busy-threads used to be ~50 with APR, now it has become ~200
with JIO.
Here are the connector definitions for reference (
0:09 +0100, Pid wrote:
> On 05/03/2010 08:41, Taylan Develioglu wrote:
> > Pid, that would assume we had a working< 1.6.10 version before that we
> > replaced.
>
> That it would.
>
> > We've run 1.6.10 upwards succesfully for a very long time. So I don't
>
Pid, that would assume we had a working < 1.6.10 version before that we
replaced.
We've run 1.6.10 upwards succesfully for a very long time. So I don't
see the point in doing this.
On Wed, 2010-03-03 at 12:00 +0100, Pid wrote:
> On 03/03/2010 09:11, Taylan Develioglu wrote:
&g
ugh I
> have never been able to develop a meaningful stress test, i.e., the only way
> I can test a change is to put it in production.
>
> Thanks,
>
> Carl
>
> - Original Message -
> From: "Taylan Develioglu"
> To: "Tomcat Users List"
for some reason I keep calling you chuck... I hope I'm not offending
anyone :O
On Fri, 2010-02-26 at 13:55 +0100, Taylan Develioglu wrote:
> Chuck I am aware.
>
> A SIGSEGV is a signal sent by the kernel. Not a violation itsself.
>
> A sigsegv is sent when an invalid memory
point in doing that (doesn't fix the problem).
On Thu, 2010-02-25 at 22:38 +0100, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Taylann,
>
> On 2/24/2010 8:31 AM, Taylan Develioglu wrote:
> > Most memory is commited to tomcat, where a
00, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Taylan,
>
> On 2/24/2010 8:31 AM, Taylan Develioglu wrote:
> > We have also had failures with hotspot error files (hs_err) present, and
> > the cause specified was indeed SIGSEGV ind
I'll be sure to post an update if u16 resolves it. Or any other progress
for that matter.
In the meantime don't be shy either :)
On Wed, 2010-02-24 at 14:52 +0100, Carl wrote:
> Taylan,
>
> > The failures we've seen are in anywhere between 8 hours to a week of
> > runtime.
>
> The timing of the
, offhand, what (if any)
> results Carl had with other JVMs.
>
>
> p
>
>
> * Perhaps there's a subtle bug in recent releases of the JVM.
>
>
> > On Wed, 2010-02-24 at 11:28 +0100, Konstantin Kolinko wrote:
> >> 2010/2/24 Taylan Develioglu:
>
. I am running a couple of
> applications and it seems the failures are more frequent when people are
> hitting the additional apps (the primary app is always used, the remaining
> apps are used sporatically.)
>
> How does this compare to what you are experiencing?
>
&g
and apache on machines with
debian 5.0 that synchronize their clock using clock slew (ntpdate) and
decreased the ntpdate frequency to see if that helps. ((as you can tell
I'm getting a bit desperate)
On Wed, 2010-02-24 at 11:28 +0100, Konstantin Kolinko wrote:
> 2010/2/24 Taylan Develio
d 's/M$\|G$//')/6))M
JAVA_PERM_SIZE=128M
JAVA_STCK_SIZE=128K
EDEN_SIZE is 1/6th of total heap.
And I said there was nothing in the system logs.
But you get a couple of points for trying.
On Wed, 2010-02-24 at 10:44 +0100, Pid wrote:
> On 24/02/2010 09:36, Taylan Develioglu wrote:
&g
I thought I'd add the connector definitions too, :
On Wed, 2010-02-24 at 10:23 +0100, Taylan Develioglu wrote:
> Hi,
>
> I have jvm's, running tomcat and our application, exiting mysteriously,
> and was wondering if anyone could give me some advice on how
Hi,
I have jvm's, running tomcat and our application, exiting mysteriously,
and was wondering if anyone could give me some advice on how to debug
this thing.
There is nothing in catalina.out, nor our application logs, and no
hotspot error file. GC log looks normal. No trace in system logs.
I am
Skimmed quickly through your post there while working, so forgive me if
this is irrelevant.
CLOSE_WAIT is a state where the connection has been closed on the tcp/ip
level, but the application (in this case java) has not closed the socket
descriptor yet.
As a coincidence we just fixed this very sa
ess.
Caldarale, Charles R wrote:
>> From: Taylan Develioglu [mailto:tdevelio...@ebuddy.com]
>> Subject: Re: CPU usage with APR and connectionTimeout impact
>>
>> according to the documentation there exists no connectionTimeout
>> attribute for the apr connector.
>>
Funny,
according to the documentation there exists no connectionTimeout
attribute for the apr connector.
Setting the value to '0' could mean all sorts of behavior, no way to
know for sure short of checking the code. (it could mean the connector
will not wait for the uri line at all)
I can't co
and it pre-compiles all of its code before it runs each script"
For starters, I'd point out the jsp page compiler does this as well...
Then redirect the person to this thread to get lynched. (seriously,
aside from the lynching this is a good idea)
---
Hi Andre,
I meant to stop writing, not closing the socket. Poor choice of words,
apologies.
André Warnier wrote:
Taylan Develioglu wrote:
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
No, you'd need to modify the source. It's not particula
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
No, you'd need to modify the source. It's not particularly useful in
most scenarios to intentionally stall an HTTP conversation, so it's not
a built-in feature :)
No, I'm saying that you should send exactly
hristopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
On 3/6/2009 4:05 AM, Taylan Develioglu wrote:
James, thank you very much.
I suspected IE to be guilty because it was happening only with IE clients.
Chris, I guess we don't need to try and reproduce this anymo
Possibly IE writes to the socket buffer in seperate steps for header
info and post parameters. This would cause the data to be sent out in
seperate packets if nagle's alg. is off.
Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: tomcat w/
SHA1
Taylan,
On 3/5/2009 5:11 AM, Taylan Develioglu wrote:
I always hold this as a ground rule:
Increase heapsize as much as possible as long as:
My rule has always been to run with the smallest heap you can get away
with. We ran our main production app in 64MB of heap (the default for
our
vious post :
question : encounter java.net.SocketTimeoutException: Read timed out
occasionally
in below URL :
http://www.nabble.com/question-%3A-encounter-java.net.SocketTimeoutException%3A-Read-timed-out-occasionally-td19326602.html#a19832518
On Thu, Mar 5, 2009 at 6:45 PM, Taylan Develioglu wrote
009 2:07 PM, Taylan Develioglu wrote:
I can reproduce it on demand with our application, but I wouldn't know
how to create a post request that would stall, the servlet can stall the
response, but isn't processing of the request (i.e. fetching post
parameters) done by tomcat?
Yo
I always hold this as a ground rule:
Increase heapsize as much as possible as long as:
latency goals are met (gc does note take too long)
enough memory is spared for system and vm. (enough to compensate for
spikes, watch your swap usage to determine this)
hope this helps a bit
Peter Crowther
o:ch...@christopherschultz.net]
Sent: dinsdag 3 maart 2009 18:53
To: Tomcat Users List
Subject: Re: tomcat w/apr data lost in http post request?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Taylan,
On 3/3/2009 12:11 PM, Taylan Develioglu wrote:
> Thanks for the thoughts Chris, but I found the
Thanks for the thoughts Chris, but I found the cause.
I had lowered the the keepalivetimeout setting to 10s because our
application polls in 2.5s intervals, pretty unexpected result (I figured
10s should be enough).
I think the connection gets closed somewhere in the middle of the post
request b
I would like to correct this, it seems to only happen with IE6/7.. maybe
old firefox 2.0
> It happens with different clients indeed.
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-
t;
> So basically, it seems that whatever Ajax library you are using, is
> issuing HTTP requests that violate the official specs.
>
> The problem as I see it, is that in such circumstances, the behaviour
> of whatever server module is processing these requests, becomes
> unpredictab
Hi Gregor,
It happens with different clients indeed.
We have redirectport="443" to a another connector yes, but how could
this be of influence on regular http requests?
Is disableUploadTimeout a supported option for the apr connector? The
documentation only mentions it under the HTTP connector.
- Apologies, I pressed send too soon.
The tomcat version I'm using is 6.0.18 w/ apr 1.3.3
Sun jdk 6u12 on debian 4.0.
following is the connector defined:
Thank you
Hi,
I'm having an issue where the payload from http POST requests is lost.
This happens when using the APR connec
Hi,
I'm having an issue where the payload from http POST requests is lost.
This happens when using the APR connector, although sometimes it happens
with NIO too (but much less frequently).
Http headers are there, but the actual payload is missing (or at least
isn't reaching our application, but w
Guys, I've been following this thread for a while now, but doesn't
Jmeter already do what you're trying to accomplish here?
I've used jmeter's proxy to record and replay http requests/responses
before with success.
Or am I missing something here?
Here's a link to some instructions :
http://jakar
omcat Users List
Subject: RE: Fatal error: Cleaner terminated abnormally
> From: Taylan Develioglu [mailto:tdevelio...@ebuddy.com]
> Subject: Re: Fatal error: Cleaner terminated abnormally
>
> By trapping the exit call using security manager we hope to prevent
> Tomcat from closing do
This is bad news, but it was a longshot to begin with.
I submitted a bug report which is under review now.
and apologies for the name mixup. Chuck is obviously a much prettier name :)
Caldarale, Charles R wrote:
>> From: Taylan Develioglu [mailto:tdevelio...@ebuddy.com]
>> Subjec
We're trying a workaround now.
By trapping the exit call using security manager we hope to prevent
Tomcat from closing down on a cleaner termination.
Not sure what the side effects would be to keep running after a cleaner
terminates (any idea). Keeping fingers crossed.
I forgot to say thanks fo
I found bug 4938372, but it didn't seem related to me at the time.
There's a post dated 2007, from Alan Bateman, indicating they'd try
putting the fix in a java 6 update.
I'll submit a bug report and in the meanwhile explore other options such
as native/apr then.
-Original Message-
From
Yes, 64-bit hotspot server vm.
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: dinsdag 17 februari 2009 16:23
To: Tomcat Users List
Subject: Re: Fatal error: Cleaner terminated abnormally
Taylan Develioglu wrote:
> Following the gc trail, it looks like an
when
using native/apr ?
As always, any comment is appreciated.
- Taylan
-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: dinsdag 17 februari 2009 16:36
To: Tomcat Users List
Subject: RE: Fatal error: Cleaner terminated abnormally
> From: Taylan De
Hi Guys,
Our application is a servlet running in a container in Tomcat
standalone. It uses the following NIO connector definition:
Lately we've been experiencing a fatal error, related to gc, with Tomcat
that causes it to stop and unload, which I hoped you could give some
advice for.
I'm s
49 matches
Mail list logo
