Eclipse debugger always blocks on ThreadPoolExecutor without any obvious exception, why?

Question

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.

There's a more specific solution, which prevents Eclipse breaking on RuntimeExceptions thrown only from a given class.

1. Add a new exception breakpoint from the Debugging perspective
2. Go to its properties
3. Go to Filtering
4. In "Restrict to Selected Location(s)", click "Add Class"
5. Add java.util.concurrent.ThreadPoolExecutor
6. Untick the checkbox, meaning these will be ignored

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

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.