******************************* 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
also.
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.
Jeff
-----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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Konstantin,
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
