> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> Subject: RE: Thread dump analysis
>
> And what about Tomcat 5 with JDK6?
I don't run Tomcat 5 much anymore, but what little I have done with it seems to
be fine on JDK 6.
- Chuck
THIS COMMUNICATION MAY CONTAIN CO
Charles, List,
>Hmmm... could be a JVM bug, or might be a conflict with classes in your
>webapp. Do you happen to have some XML-related jars in >your webapp or
>otherwise visible to that branch of the classloader tree? (I guess you
>answered that below.)
Well, actually, the developers also i
> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> Subject: Re: Thread dump analysis
>
> Now, I don't know why (since I'm a noob programmer), but it seems that
> the implementation of Xerces that is included in JDK6 is causing the
> application to hang.
Hm
Hi.
For all of you who were so kind to respond to my problem a few days ago,
and for others who'd like to know, I think I have found the problem.
As mentioned in earlier mails, the application I monitor hangs after a
random amount of time. Using jconsole and virtualvm I managed to detect
the thre
Hi Chuck
>> Could it be that Tomcat ran out of connectors (maxThreads
>> was hit) and after a while they get closed by the timeout?
>Depends on how your DB connector pool is configured.
I was actually referring to the limit of http connections, set by maxThreads.
>> This could be a plausible e
> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> Subject: Re: Thread dump analysis
>
> Could it be that Tomcat ran out of connectors (maxThreads
> was hit) and after a while they get closed by the timeout?
Depends on how your DB connector pool is configured.
&g
> Do I understand you correctly, that after you killed the first tomcat
> (in my understanding the one which fires soap requests, tomcat 5) than
> all the RUNNABLE threads in the second tomcat (the one that answers
> soap, tomcat 6 with xfire) went away and it (tomcat) was idle?
No, I did not res
Thanks Chris,
I just bumped into a very nice plugin for Jconsole called "TopThread".
It's a linux top alike and shows the CPU usage of all threads.
This only confirms what I figured out before, there are two threads
taking up all CPU. See below for their stack trace:
com.sun.org.apache.xerces.int
I omit the whole quoting to save traffic for clarity.
Do I understand you correctly, that after you killed the first tomcat
(in my understanding the one which fires soap requests, tomcat 5) than
all the RUNNABLE threads in the second tomcat (the one that answers
soap, tomcat 6 with xfire) went awa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pieter,
Pieter Temmerman wrote:
> Memory usage looks healthy, but CPU usage goes sky high (mainly caused
> by the Java Tomcat process).
That's interesting. Looking at your thread dump snippet, it looks like
your database connection pool is exhausted.
>If the threadMax would be too low in the connector, wouldn't the
> "freeze" be over once there are free connections? And also, how can a
> small threadMax make a thread hang? For example the one that is trying
> to read an XML file.
As a follow up on my own question. This is what the docs say:
A
I really appreciate your input Leon.
On Wed, 2009-01-28 at 11:07 +0100, Leon Rosenberg wrote:
> > "RMI TCP Connection(42)-173.x.x.x" - Thread t...@112
> > java.lang.Thread.State: RUNNABLE
>
> reading from socket, usually not a problem.
>
I thought so. Thanks.
> > "http-8081-35" - Thread t...
On Wed, Jan 28, 2009 at 10:42 AM, Pieter Temmerman
wrote:
>
>
>>Have you found any java.lang.Thread.State: RUNNABLE threads? They are
>>usually more interesting if it comes to a high cpu :-)
>
> These are the RUNNABLE threads on Tomcat 6:
>
> "RMI TCP Connection(42)-173.x.x.x" - Thread t...@112
>
Thanks to all for your helpful input.
As a result of trying to reproduce the problem on pre-production
servers, I used JMeter to generate some load.
Let me give some more specific information about the setup.
I have two Tomcat servers:
- Tomcat 5.5.7 (jdk 1.5.0_09) (I know, it's old. But this i
> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> Subject: Thread dump analysis
>
> Memory usage looks healthy, but CPU usage goes sky high (mainly caused
> by the Java Tomcat process).
If you're truly out of memory, the GC thread(s) may be running almost
continuously. However, with m
Have you found any java.lang.Thread.State: RUNNABLE threads? They are
usually more interesting if it comes to a high cpu :-)
Also, as David posted, what is the HEAP usage? it's usually at the end
of the dump.
regards
Leon
On Mon, Jan 26, 2009 at 5:37 PM, Pieter Temmerman
wrote:
> Hi all.
>
> I'
We spent weeks looking at similar bizarre thread stack dumps.
Eventually it turned out to be a GC problem. The JVM will all
of a sudden decide to stop large numbers of threads from running
(or perhaps it stops one, but that thread happens to be holding
a heavily contended lock --- database connect
17 matches
Mail list logo
