https://issues.apache.org/bugzilla/show_bug.cgi?id=50306

--- Comment #9 from TomLu <dirtcham...@hotmail.com> 2011-03-14 10:30:23 EDT ---
Created an attachment (id=26769)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26769)
New Valve: StuckThreadDetectionValve

Looking at the source, a Valve seems like a much better place for such code as
you wrote. However, I still think we need some kind of a threshold
(configurable or not). Deadlocked threads are not the only problem we can face.
We are often experiencing problems with erronous data in our DB, which causes
loops to occur. Http client request without any configured read or connect
timeout can also cause a thread to appear "stuck". The threads this Valve
should monitor are HTTP/AJP processor threads only (not user threads), and
these threads should _normally_ not be processing long running requests. Such
requests should preferably be allocated to a separate thread if possible. Users
who do need to execute long running request in the HTTP/AJP threads can choose
not to use this Valve. This seems to be the spirit of Tomcat 7.x: create tools
to help users improve their apps (Ref memory leakage detection logic). In many
servers, the main HTTP request threads are considered a limited resource, and
thus if such threads are running for too long, the pool will eventually be
depleted. This is the case for WebSphere, which has a default max pool size of
50, and a configurable threshold for it's "hung thread detection" (Default 600
seconds). A valve for detecting "long running threads" can be quite helpful not
only in development, but also in production environments in many cases. This
valve should probably be disabled by default.

I have now moved the code i previously posted to a Valve. I have attached a
patch for Tomcat 7.0.11 if anyone wants to add stuck thread detection logic to
their Tomcat instance.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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

Reply via email to