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