tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 50306] Detect stuck threads
Date Mon, 22 Nov 2010 14:13:49 GMT

--- Comment #4 from Rainer Jung <> 2010-11-22 09:13:44 EST ---
I see basically two aspects that code inside Tomcat could add:

1) Extraction of relevant information

Since we know, which thread works on which request and we know a lot about the
request meta data (e.g. when it started) and about the threads (e.g. CPU
usage), we can very efficiently inspect the stacks for exactly those threads
that work on the same request for longer than some configured limit. No need to
dump stacks for all threads (a lot of them idle in the pools or connected to
the web server but not working on a request).

2) Reduction of polling interval

Since we focus on the relevant info we can do more frequent checks than one
would do with a plain "dump all stacks". E.g. every 10 seconds instead of every
one minute. If there is no long running request, no stack to inspect.

Yes, all of that can be done by a JMX client. But the client needs to be
powerful enough to add logic like retrieving the in-flight requests, extracting
those that already take to long, then retrieving the stacks for those requests

What I don't have a nice idea about is how to actually use that information. Of
course you could simply log the stacks and the request meta data for the long
running requests, but for an average admin this might be to technical (of no
real use). Though it would be helpful for his application provider when he
starts analyzing reasons for performance problems.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message