Current behavior: When undeploying an web app, tomcat first tries to check whether a container thread is still handling request, if so, it will log a warning message. Furthermore, if clearReferencesStopThreads is configured to be true, tomcat will try to call Thread.stop to stop the thread in order to prevent memory leak. Our scenario: We found that sometimes, a container thread is actually blocking an operation, e.g. network I/O, but for some reasons, the operation is not returned for quite a long time. I know that the best way should be application code to timeout for such an operation. But I think tomcat can do sth. rather that log a warning message. Proposed behavior: If configured, tomcat will call Thread.interrupt to force the blocking operation return and container thread to proceed. Since application code may continue to block on further operations, we can provide an option to let tomcat call Thread.interrupt for several times. If that sill does not work, the final defense is calling Thread.stop if configured. Any interest on this proposal? If so, I can provide a patch on this.
I like the idea in that interrupting a thread is a lot nicer than trying to stop it.
Thanks for showing your interest. I will submit a patch later on.
is it still up for grab?
Looks like it's been ignored for 4 years. Go for it!
Thanks for the PR. Fixed in: - master for 10.0.0-M5 onwards - 9.0.x for 9.0.35 onwards - 8.5.x for 8.5.55 onwards - 7.0.x for 7.0.104 onwards