*******************************  NOTICE  *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.
--- Begin Message ---
Well, it's definitely deadlocking once it hits the maxThreads limit.
I had this instance and another one on the same machine both hit the max last 
night and the acceptor stopped waiting on workers.  All the workers show their 
normal wait state, and some of the Pollers showed they were waiting on workers 
What I appear to be seeing is that the requests come in and get processed on a 
minimal number of workers, but at some point, new workers are getting created 
until we reach the maxThreads limit (150).  I'm not seeing a traffic load that 
indicates that it should ever be using that many workers, there are only about 
15-20 end users in the app at any one time.  I'm not seeing this on other 
systems running the same version of the app & tomcat, although they are running 
a much older native library.
I've been monitoring the instance using jconsole.
On the instance that died early last night, they were sitting at about 135 
worker threads at 8:00am and stayed there all day, even with some cursory 
logging in and checking a few pages during the day.  Then, at about 7:00pm, 
when the Asia user based started working, the Threads graph in jconsole starts 
climbing, levels for about 30 minutes, and then climbed the rest of the way 
until it hit the 150 limit.  Almost as though it wasn't using the bulk of the 
existing worker threads.  The resulting threads looked just like those in the 
previous thread dump -- all workers in normal wait state, but the Acceptor 
waiting on workers.
Question:  Could there be something that our programmers are doing (or more 
likely NOT doing) that would allow workers to return to waiting, but not 
actually be free for work?
Otherwise, I'd have to assume something in the native library is mucking up the 
thread pool count.


-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, April 15, 2010 11:42 AM
To: Tomcat Users List
Subject: Re: Hung threads

Hash: SHA1


On 4/15/2010 10:19 AM, Konstantin Kolinko wrote:
> +1.
> If it is stuck there, it will not accept any more incoming requests.

Thanks for the confirmation that Jeffrey is deadlocked.

> It might be that you bumped into BZ 48843
> https://issues.apache.org/bugzilla/show_bug.cgi?id=48843

Heh. This guy is bouncing from one bug to the next, here. Sorry, Jeffrey. :(

> A patch for it is already available, proposed, and has enough votes,
> so it will be applied shortly. That will be 5.5.30, though.

Jeffrey, do you have the inclination to apply this patch to your TC
instance? Compiling TC 5.5 was relatively simply IIRC. Or, maybe someone
would be willing to roll you a binary patch.

- -chris

--- End Message ---
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to