Bug 56526 - New option to interrupt stuck threads
New option to interrupt stuck threads
Status: RESOLVED FIXED
Product: Tomcat 8
Classification: Unclassified
Component: Catalina
8.0.x-trunk
All All
: P2 enhancement (vote)
: ----
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2014-05-14 21:20 UTC by Sylvain Laurent
Modified: 2014-05-20 19:10 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvain Laurent 2014-05-14 21:20:39 UTC
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.
Comment 1 Sylvain Laurent 2014-05-14 21:20:49 UTC
(I'm working on it right now, I created the BZ issue to get an ID for the commit message)
Comment 2 Sylvain Laurent 2014-05-16 20:06:18 UTC
committed r1595331 on tomcat 8
Comment 3 Konstantin Kolinko 2014-05-16 21:36:15 UTC
Small correction: the fix is in 8.0.9.
(Tomcat 8.0.8 was tagged an hour earlier - r1595294)

I updated the changelog file.
Comment 4 Sylvain Laurent 2014-05-19 20:38:50 UTC
merged to tomcat 7, will be available in 7.0.55.
Comment 5 Christopher Schultz 2014-05-20 18:54:12 UTC
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.
Comment 6 Sylvain Laurent 2014-05-20 19:10:13 UTC
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 ?