Bug 56526

Summary:	New option to interrupt stuck threads
Product:	Tomcat 8	Reporter:	Sylvain Laurent <slaurent>
Component:	Catalina	Assignee:	Tomcat Developers Mailing List <dev>
Status:	RESOLVED FIXED
Severity:	enhancement
Priority:	P2
Version:	8.0.x-trunk
Target Milestone:	----
Hardware:	All
OS:	All

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 ?