CODEWITHSUNDEEP
javaeclipsedebuggingtomcat
gotch4
gotch4

Reputation: 13299

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

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 exploit any new feature, I just wanted to try that). Every time I debug my application, it happens that Eclipse debugger pops out like it has reached a breakpoint, but it is not the case, in fact it stops on a Java source file that is ThreadPoolExecutor. There is no stack trace on the console, it just stops. Then if I click on resume it goes on and the app works perfectly. This is what shows in the debugger window:

Daemon Thread ["http-bio-8080"-exec-2] (Suspended (exception RuntimeException)) 
    ThreadPoolExecutor$Worker.run() line: 912   
    TaskThread(Thread).run() line: 619

I really can't explain this, because I'm not using ThreadPoolExecutor at all. Must be something from Tomcat, Hibernate or Spring. It's very annoying because I always have to resume during debugging.

Any clues?

Upvotes: 213

Views: 66205

Answers (4)

Vineet Reynolds
Vineet Reynolds

Reputation: 76719

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.

Upvotes: 298

slaurent
slaurent

Reputation: 1177

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

Upvotes: 25

DaCrazyCoder
DaCrazyCoder

Reputation: 51

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.

Upvotes: 2

DeejUK
DeejUK

Reputation: 13521

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

Upvotes: 49

Related Questions