The StuckThreadDetectionValve is able to detect stuck threads. It can be improved to also interrupt such threads to try and unblock them in case they are just stuck in I/O or network calls. This would be more or less similar to apache httpd TimeOut directive or PHP max_execution_time (http://www.php.net/manual/en/info.configuration.php#ini.max-execution-time ) and would protect the tomcat server from slow or non-responding backend services and unproperly configured timeouts in the application.
(I'm working on it right now, I created the BZ issue to get an ID for the commit message)
committed r1595331 on tomcat 8
Small correction: the fix is in 8.0.9. (Tomcat 8.0.8 was tagged an hour earlier - r1595294) I updated the changelog file.
merged to tomcat 7, will be available in 7.0.55.
I don't think Thread.interrupt will interrupt a blocking I/O operation, at least not reliably. IIRC, this "works" on *NIX but not Windows. While this patch probably makes things better, it's not an absolute solution to the problem of stuck threads. Perhaps a followup documentation patch is appropriate mentioning the caveats of attempting to "unstick" stuck threads.
well, it's not perfect, as I tried to briefly explain in the configuration doc, but in my experience, it should work in many cases where the thread is blocked on a network call. Actually that was my primary motivation for this feature. In my experience this is a good safety net against APIs that don't provide network timeouts or applications that don't configure their timeout (a very common situation with JDBC or JNDI). Instead of a documentation patch, what about a wiki page instead ?