tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leon Rosenberg" <>
Subject Re: jvm cowardly refuses to print a thread dump
Date Mon, 01 Dec 2008 18:04:25 GMT
its very weird indeed. We had acted proactively on a tomcat which
started to show same symptoms (cpu load going higher (35%) but users
going down (means it replies slower than the other machines and the lb
gives less traffic to it) and after checking the logs, sent the QUIT
signal which worked this time (hence i can't be sure, that its
completely the same problem).

But the thread dump was weird, from
51 RUNNABLE threads
38 in at Method)
2 in write to file in logging
and two in
at java.util.ArrayList.size(

Now this is something i personally consider weird, since it's hard
enough to find a thread in any places in working (not waiting) code in
a thread dump, but twice in the same code line?

The calling code line (our code) is
	public boolean isRoot() {
		return pathElements.size() == 0;

We assume that the other tomcats didn't produce any thread dumps
because our trigger happy system admins just sent the kill -9 too soon
after the kill -3, and the jvm was overloaded. Well it's a wild guess,
but i have no better one yet (unless jvm really locked up internally,
but why??? we haven't change the jvm or tomcat or os or anything for a
year now).

But back to the ArrayList, how high is the probability of having
ArrayList.size() twice in the similar call-tree in one ThreadDump?


On Mon, Dec 1, 2008 at 5:41 PM, Peter Crowther
<> wrote:
>> From: Caldarale, Charles R []
>> That's ugly.  Sounds like either the OS failed to deliver the
>> signal, or the JVM is locked up internally (probably the
>> latter).
> That's rather what I was reckoning.  I've had signal delivery fail before if all the
threads were stuck in kernel code via system calls.  This was SunOS 3.x, which shows my age
- NFS was kernel-mode at that point, which made for interesting times if file accesses got
stuck.  Processes not responding to a kill -9 was a new one on me!
> Might the code have ended up with all threads stuck in OS calls?  It feels a little unlikely,
as I assume the JVM keeps a couple of threads for itself...
>                - Peter
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message