Der Eclipse-Debugger blockiert ThreadPoolExecutor immer ohne offensichtliche Ausnahme. Warum?

209

Ich arbeite an meinen üblichen Projekten in Eclipse, einer J2EE-Anwendung, die mit Spring, Hibernate usw. erstellt wurde. Ich verwende dafür Tomcat 7 (kein besonderer Grund, ich nutze keine neue Funktion, ich wollte das nur ausprobieren). Jedes Mal, wenn ich meine Anwendung debugge, wird der Eclipse-Debugger angezeigt, als hätte er einen Haltepunkt erreicht. Dies ist jedoch nicht der Fall. Tatsächlich wird er in einer Java-Quelldatei gestoppt ThreadPoolExecutor. Es gibt keine Stapelverfolgung auf der Konsole, sie stoppt nur. Wenn ich dann auf Fortsetzen klicke, geht es weiter und die App funktioniert perfekt. Folgendes wird im Debugger-Fenster angezeigt:

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

Ich kann das wirklich nicht erklären, weil ich es überhaupt nicht benutze ThreadPoolExecutor. Muss etwas von Tomcat, Hibernate oder Spring sein. Es ist sehr ärgerlich, weil ich beim Debuggen immer weitermachen muss.

Irgendwelche Hinweise?

— gotch4
quelle

1

@ AmosM.Carpenter ist es nicht Java EE, nicht JEE? Sogar Ihr eigener Link scheint dies zu suggerieren

— eis

290

Der gepostete Stack-Trace zeigt an, dass in einem Daemon-Thread eine RuntimeException aufgetreten ist. Dies wird normalerweise zur Laufzeit nicht erfasst, es sei denn, der ursprüngliche Entwickler hat die Ausnahme abgefangen und behandelt.

In der Regel ist der Debugger in Eclipse so konfiguriert, dass die Ausführung an dem Ort, an dem die Ausnahme ausgelöst wurde, für alle nicht erfassten Ausnahmen angehalten wird . Beachten Sie, dass die Ausnahme möglicherweise später im Stapelrahmen behandelt wird und möglicherweise nicht dazu führt, dass der Thread beendet wird. Dies wäre die Ursache für das beobachtete Verhalten.

Konfigurieren Sie das Verhalten von Eclipse ist einfach:
Gehen Sie zu Fenster > Einstellungen > Java > Debug und deaktivieren Suspend Ausführung auf nicht abgefangene Ausnahmen .

— Vineet Reynolds
quelle

In meinem Fall stackoverflow.com/questions/8911146/… hat es nicht geholfen :-(

— Gangnus

5

Ich habe den Eclipse-Fehler 384073 dazu angemeldet, da diese Option beim Debuggen von Web-Apps im Wesentlichen unbrauchbar wird.

— Daniel Serodio

9

Das Deaktivieren der Option "Ausführung bei nicht erfassten Ausnahmen anhalten" in Eclipse ist eine schlechte Problemumgehung: Was ist, wenn Eclipse bei echten nicht erfassten Ausnahmen angehalten werden soll, z. B. aufgrund Ihres eigenen Codes? Es scheint mir, dass dies ein Fehler in Tomcat ist ...

3

@ Luis: Ich habe mich das auch gefragt! Wie pro bugs.eclipse.org/bugs/show_bug.cgi?id=384073#c4 kann man: Deaktivieren der globalen Stützpunkte, erstellen Sie einen neuen Haltepunkt auf java.lang.Exception und wenden einen exklusiven Filter gegen diesen neu geschaffenen Breakpoint.

— rektide

3

@ Daniel ... Vielleicht ist es besser, ein Problem beim Tomcat-Team einzureichen. Ich denke, dieses Verhalten ist neu in Tomcat 7 ... Eclipse macht das, was es tun soll ... (hätte nie gedacht, dass ich eines Tages Eclipse verteidigen würde ... :)

— Stijn de Witt

47

Es gibt eine spezifischere Lösung, die verhindert, dass Eclipse auf RuntimeExceptions bricht , die nur von einer bestimmten Klasse geworfen werden.

Fügen Sie aus Sicht des Debuggens einen neuen Ausnahme-Haltepunkt hinzu
Gehe zu seinem Eigenschaften
Gehe zu Filtern
Klicken Sie unter "Auf ausgewählte Speicherorte beschränken" auf " Klasse hinzufügen" " auf ".
Hinzufügen java.util.concurrent.ThreadPoolExecutor
Deaktivieren Sie das Kontrollkästchen , dh diese werden ignoriert

— EngineerBetter_DJ
quelle

1

Ich kann es scheinbar nicht mit Tomcat 7 und Eclipse / STS 3.4.0 zum Laufen bringen. Sind weitere Einstellungen erforderlich? Sollte dieser Haltepunkt am registriert werden RuntimeException? Muss es aktiviert oder deaktiviert sein? Sollten "Gefangene Orte" und "Nicht gefangene Orte" ein- oder ausgeschaltet sein?

— Henrik Heimbuerger

2

Es scheint, dass der Ausnahme-Haltepunkt eine java.lang.RuntimeException sein muss, aktiviert sein muss, nur für nicht erfasste Speicherorte gelten darf und die Klasse java.util.concurrent.ThreadPoolExecutor nicht überprüft werden darf.

— Mario

Leider ist unter Ubuntu 14.04 die Option "Auf ausgewählte Speicherorte beschränken" für Eclipse Luna 4.4.0 nicht verfügbar.

— eeezyy

24

Dieses Verhalten wird von Tomcat ausgelöst, wenn eine Webanwendung neu geladen wird. Es ist Teil der Tomcat-Funktion "Memory Leak Protection" , die (unter anderem) die Erneuerung ihrer Threads erzwingt.

Dies wurde jetzt in den Versionen 7.0.54 und 8.0.6 von Tomcat behoben: https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

— slaurent
quelle

2

Ich habe festgestellt, dass dies häufig nach dem Ändern von Serverdateien (jsp oder java) auftritt und STS Probleme beim erneuten Laden der Anwendung hat.

Dies führt normalerweise zu einem Neustart des Servers, damit die Änderungen synchronisiert werden.

Nach der Einführung von JRebel scheint es verschwunden zu sein. Daher würde ich gerne glauben, dass es sich bei STS um ein reproduzierbares Problem handelt, wenn Hotswapping-Code im Debug-Modus ausgeführt wird.

Durch das Entfernen des nativen Hotswapping wird das Problem behoben, dass es innerhalb der ThreadPoolExecutor-Klasse beschädigt wird.

— DaCrazyCoder
quelle