views:

1269

answers:

5

Running Tomcat through eclipse works fine in non-debug mode, but not in debug mode. When I try to start the Tomcat server in debug mode, the console output looks fine for a while, but then starts slowing down and eventually just stops, pegging the cpu at 100%. I don't think it's relevant, but just in case - here's the console output right about when it starts slowing down and eventually stopping (by stopping I mean no more console output, but still 100% cpu).

2009-09-02 14:35:30,859 INFO   NONE org.springframework.context.weaving.DefaultContextLoadTimeWeaver:72 - Found Spring's JVM agent for instrumentation
2009-09-02 14:35:49,562 INFO   NONE org.springframework.beans.factory.support.DefaultListableBeanFactory:414 - Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@ed889d: defining beans [...
2009-09-02 14:37:31,031 INFO   NONE org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean:221 - Building JPA container EntityManagerFactory for persistence unit ...

I tried everything I could think of to fix it:

  • cleanesd tomcat working directory
  • restarted eclipse
  • restarted Windows
  • refreshed/cleaned all projects

I first had this problem last week using eclipse ganymede. I had been running fine in debug-mode for several months prior to this issue. I didn't make any significant changes to our project that would cause this. Eventually, I upgraded to eclipse galileo which solved my problem. Now 2 days later, I'm having the same problem in galileo. Like I said it works fine in non-debug mode. Any help is much appreciated.

I should add that other things work in debug mode - for instance junit tests, so it is something specific to tomcat.

+9  A: 

I've gotten through the issue! Once I figured it out, I remember that this has happened before. I cleared all my breakpoints and it works fine. I have no idea why that would cause the outcome that is does, but it works.

andersonbd1
worked for me as well when I was having this problem today
Ayrad
Thanks for this advice, can't upvote you more! =))
elder_george
Happened to me too and cleaning breakpoints helped.. It's weird though.. :)
kane77
Worked for me too.
ich-bin-drin
God bless you :)))
Gian Marco Gherardi
A: 

I just ran into this problem myself, and this solution helped me out. However - I only had 1 breakpoint, rather than the 20+ of other posters. My one breakpoint, however, was a method breakpoint and not a line breakpoint - I wonder if the multitude of method calls at tomcat startup combined with the method breakpoint could be causing this problem... I just tried a small experiment:

  1. Setting a line breakpoint and starting debug mode - 5 second startup (normal)
  2. Setting a method breakpoint and starting debug mode - ..... not willing to wait (> 90 seconds).

I'm guessing this is the problem.

Chris Goddard
A: 

Change default logging level from:

<root>
  <level value="DEBUG" />
  <appender-ref ref="ConsoleAppender" />
</root>

To :

<root>
  <level value="OFF" />
  <appender-ref ref="ConsoleAppender" />
</root>
Jamal
A: 

Clearing out your braekpoints is not the answer. I have a brand new workspace with no breakpoints and after starting my Tomcat6 server my CPU jumped up to 100%.

POJD
A: 

I had this same problem in Galileo. Fast run but crawling debug. Thanks to the posts above, I cleared all the breakpoints and restarted Tomcat. That magically fixed the problem. fyi - I had 2 method breakpoints and other line breakpoints earlier. I did the tests to confirm the above theory about method breakpoints slowing down. Here's what I found. Looks like it's not the method breakpoint which is the problem, the problem was the method breakpoint which was still showing up in the breakpoints list in debug view, but was not existing in the code. I mean I changed the parameters of that method but the old breakpoint with older parameters was still existing in the breakpoint list. That was the culprit, when I removed that, the other method breakpoints did not slow down the server. So looks like eclipse was trying to search for something non-existing which seems to have slowed it down. Hope this helps.

vsc