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
