https://bz.apache.org/bugzilla/show_bug.cgi?id=59203
Bug ID: 59203
Summary: Try to call Thread.interrupt before calling
Thread.stop in
WebappClassLoaderBase#clearReferencesThreads
Product: Tomcat 9
Version: 9.0.0.M4
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: huxing.zh...@gmail.com
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.
--
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
