> -Original Message-
> From: Charles Richard [mailto:charle...@thelearningbar.com]
> Sent: Thursday, May 09, 2013 7:03 AM
> To: Tomcat Users List
> Subject: Re: Tomcat thread dump analysis
>
> On Wed, May 8, 2013 at 6:16 PM, Christopher Schultz <
> ch...@ch
On Wed, May 8, 2013 at 6:16 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Charles,
>
> On 5/8/13 1:57 PM, Charles Richard wrote:
> > I appreciate the friendly feedback! How do I show a lock? I don't
> > see any threads that h
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: Tomcat thread dump analysis
> > It would appear that logic in your application threads has either
> > created a deadlock, or failed to unlock something before
> > returning,
> That&#
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles,
On 5/8/13 1:57 PM, Charles Richard wrote:
> I appreciate the friendly feedback! How do I show a lock? I don't
> see any threads that have a "BLOCKED" status. I do get this when I
> do a grep:
>
> [root@web01 stacks]# grep locked tomcat1_20
bar.com]
> >> Subject: Re: Tomcat thread dump analysis
> >
> >> Here is a full thread dump
> >
> > Which again shows no Tomcat involvement in the locking hang.
>
> +1
>
> At least it confirms OP is actually running Tomcat, which wasn't
> eviden
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chuck,
On 5/8/13 11:25 AM, Caldarale, Charles R wrote:
>> From: Charles Richard [mailto:charle...@thelearningbar.com]
>> Subject: Re: Tomcat thread dump analysis
>
>> Here is a full thread dump
>
> Which again shows n
> From: Charles Richard [mailto:charle...@thelearningbar.com]
> Subject: Re: Tomcat thread dump analysis
> Top-posting is a post after another one I'm assuming?
No, it's doing what you keep on doing - posting the response before the query
it applies to (you could have l
Chris,
Top-posting is a post after another one I'm assuming? And sorry if it
wasn't related to Tomcat, I was just excited to finally making a bit of
headway on this issue.
Here is a full thread dump, sorry in advance if this doesn't follow the
etiquette on posting thread dumps:
"TP-Processor396"
On May 8, 2013, at 8:39 AM, Charles Richard wrote:
> Just saw this which I believe describes exactly what is happening:
>
> http://forums.terracotta.org/forums/posts/list/6470.page
>
> We are using Spring as well. Trying to understand the solution:
If this is the problem that you're experienci
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles,
On 5/8/13 8:31 AM, Charles Richard wrote:
> On Wed, May 8, 2013 at 9:27 AM, Daniel Mikusa
> wrote:
>> On May 8, 2013, at 8:20 AM, Charles Richard wrote:
>>
>>> Hi,
>>>
>>> We have a weird issue on our site which some random trigger
>>> e
Just saw this which I believe describes exactly what is happening:
http://forums.terracotta.org/forums/posts/list/6470.page
We are using Spring as well. Trying to understand the solution:
Charles
On Wed, May 8, 2013 at 9:31 AM, Charles Richard <
charle...@thelearningbar.com> wrote:
> We are u
We are using Terracotta which is a bit of a black box to me (setup I've
inherited). Terracotta helps us with the Tomcat sessions being
"transportable" across front end servers.
Cheers!
Charles
On Wed, May 8, 2013 at 9:27 AM, Daniel Mikusa wrote:
>
> On May 8, 2013, at 8:20 AM, Charles Richard
On May 8, 2013, at 8:20 AM, Charles Richard wrote:
> Hi,
>
> We have a weird issue on our site which some random trigger event will
> backup all c3p0 connections until it hits the max pool size.
>
> I have scripts that will do a softReset on the c3p0 connection pool when
> they hit their max so
Oh and sorry, we are using Tomcat 6.0.30 .
Cheers!
On Wed, May 8, 2013 at 9:20 AM, Charles Richard <
charle...@thelearningbar.com> wrote:
> Hi,
>
> We have a weird issue on our site which some random trigger event will
> backup all c3p0 connections until it hits the max pool size.
>
> I have sc
Hi,
We have a weird issue on our site which some random trigger event will
backup all c3p0 connections until it hits the max pool size.
I have scripts that will do a softReset on the c3p0 connection pool when
they hit their max so help us manage the issue and to also help me have
time to hopefull
Hello,
tomcat 6.0.26
jvm 1.5.0_16
i'm trying to tune tomcat, avoiding some timeout i think come from the
database.
Where can i find info about thread analysis? I'm using Visual VM to see
the thread status, but so far i know:
1) TP-Processor[x] are the request handling threads
2) RMI and JMX are
> 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
>
e for any pointers you are able to give me.
On Mon, 2009-01-26 at 11:33 -0600, Caldarale, Charles R wrote:
> > From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> > Subject: Thread dump analysis
> >
> > Memory usage looks healthy, but CPU usage goes sky high (mainly caus
> 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
continuo
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
Hi all.
I've been investigating why one of our applications (running in Tomcat
5.5.7) suddenly freezes after a variable amount of time (sometimes
10min, sometimes 2 hours).
Disclaimer: I'm not the developer of the application, nor do I know the
exact details of how stuff is implemented. I know..i
34 matches
Mail list logo
