Summary: | Avoid eclipse debugger pausing on uncaught exceptions when tomcat renews its 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 | ||
Attachments: | proposed patch for tomcat 8 |
Description
Sylvain Laurent
2014-05-05 21:10:01 UTC
Created attachment 31592 [details]
proposed patch for tomcat 8
My question would be why there is an exception thrown here to handle this case at all. Instead, why not check to see if we should die cleanly, then emit the recycling message to the log and simply exit the run method? I don't understand why an exception is being used here at all. (In reply to Christopher Schultz from comment #2) > My question would be why there is an exception thrown here to handle this > case at all. Instead, why not check to see if we should die cleanly, then > emit the recycling message to the log and simply exit the run method? > > I don't understand why an exception is being used here at all. Because actually in normal operation those threads never go out of java.util.concurrent.ThreadPoolExecutor.runWorker(Worker) unless there are more threads than the corePoolSize and the task queue is empty. So, when I worked on the renewal of threads to avoid classloader leaks upon undeployment, the only way I found was to throw an exception in our implementation of ThreadPoolExecutor.afterExecute(Runnable, Throwable). Is it OK for me to commit on tomcat 8 trunk? Trunk is CTR, so fire away. If you wrote the original code, I can't think of a better person to refactor it :) committed to tomcat 8 trunk : r1593132 what about tomcat 7 ? is it still CTR as stated in https://wiki.apache.org/tomcat/TomcatVersions |