I\'m working on my usual projects on Eclipse, it\'s a J2EE application, made with Spring, Hibernate and so on. I\'m using Tomcat 7 for this (no particular reason, I don\'t e
I have noticed that this often occurs after modifying server files (jsp or java) and STS has trouble reloading the application.
This usually leads to restarting the server in order to get it to get the changes synchronized.
After introducing JRebel - it appears to have gone away. So, I would like to think it is a reproducible issue in STS when hotswapping code in debug mode.
By removing the native hotswapping, it eliminates the issue with it breaking inside the ThreadPoolExecutor class.
The posted stack trace indicates that a RuntimeException was encountered in a Daemon thread. This is typically uncaught at runtime, unless the original developer caught and handled the exception.
Typically, the debugger in Eclipse is configured to suspend execution at the location where the exception was thrown, on all uncaught exceptions. Note that the exception might be handled later, lower down in the stack frame and might not lead to the thread being terminated. This would be cause of the behavior observed.
Configuring the behavior of Eclipse is straightforward:
Go to Window > Preferences > Java > Debug and uncheck Suspend execution on uncaught exceptions.
This behavior is triggered by tomcat when a webapp is reloaded. It's part of tomcat "memory leak protection" feature that (among other things) forces the renewal of its threads.
This is now fixed from versions 7.0.54 and 8.0.6 of tomcat : https://issues.apache.org/bugzilla/show_bug.cgi?id=56492
There's a more specific solution, which prevents Eclipse breaking on RuntimeException
s thrown only from a given class.
java.util.concurrent.ThreadPoolExecutor