Le débogueur Eclipse bloque toujours sur ThreadPoolExecutor sans exception évidente, pourquoi?

209

Je travaille sur mes projets habituels sur Eclipse, c'est une application J2EE, faite avec Spring, Hibernate et ainsi de suite. J'utilise Tomcat 7 pour cela (sans raison particulière, je n'exploite aucune nouvelle fonctionnalité, je voulais juste l'essayer). Chaque fois que je débogue mon application, il arrive que le débogueur Eclipse apparaisse comme s'il avait atteint un point d'arrêt, mais ce n'est pas le cas, en fait il s'arrête sur un fichier source Java qui l'est ThreadPoolExecutor. Il n'y a aucune trace de pile sur la console, elle s'arrête juste. Ensuite, si je clique sur reprendre, cela continue et l'application fonctionne parfaitement. C'est ce qui apparaît dans la fenêtre du débogueur:

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

Je ne peux vraiment pas l'expliquer, car je n'utilise pas ThreadPoolExecutordu tout. Doit être quelque chose de Tomcat, Hibernate ou Spring. C'est très ennuyeux car je dois toujours reprendre pendant le débogage.

Des indices?

java eclipse debugging tomcat gotch4
la source
1
@ AmosM.Carpenter n'est-ce pas Java EE, pas JEE? Même votre propre lien semble le suggérer
eis

Réponses:

290

La trace de pile publiée indique qu'une RuntimeException a été rencontrée dans un thread Daemon. Cela n'est généralement pas détecté lors de l'exécution, sauf si le développeur d'origine a détecté et géré l'exception.

En règle générale, le débogueur dans Eclipse est configuré pour suspendre l'exécution à l'emplacement où l'exception a été levée, sur toutes les exceptions non interceptées . Notez que l'exception peut être gérée plus tard, plus bas dans le cadre de la pile et ne pas entraîner la terminaison du thread. Ce serait la cause du comportement observé.

La configuration du comportement d'Eclipse est simple:
allez dans Fenêtre > Préférences > Java > Déboguer et décochez Suspendre l'exécution sur les exceptions non interceptées .

Vineet Reynolds
la source
Dans mon cas, stackoverflow.com/questions/8911146/… cela n'a pas aidé :-(
Gangnus
5
J'ai déposé le bogue Eclipse 384073 à ce sujet car cela rend essentiellement cette option inutilisable lors du débogage des applications Web.
Daniel Serodio
9
La désactivation de la fonction "Suspendre l'exécution sur les exceptions non capturées" sur Eclipse est une mauvaise solution: que se passe-t-il si vous voulez qu'Eclipse suspende sur de vraies exceptions non capturées, provenant par exemple de votre propre code? Il me semble que c'est un bug dans Tomcat ...
3
@Luis: Je me suis demandé la même chose! Selon bugs.eclipse.org/bugs/show_bug.cgi?id=384073#c4 , on peut: désactiver les points d'arrêt globaux, créer un nouveau point d'arrêt sur java.lang.Exception et appliquer un filtre exclusif sur ce point d'arrêt nouvellement créé.
rektide
3
@Daniel ... Peut-être préférable de signaler un problème à l'équipe Tomcat. Je pense que ce comportement est nouveau dans Tomcat 7 ... Eclipse fait ce qu'il est censé faire ... (jamais pensé que je finirais par défendre Eclipse un jour ... :)
Stijn de Witt
48

Il existe une solution plus spécifique, qui empêche la rupture d'Eclipse sur RuntimeExceptionles lancés uniquement depuis une classe donnée.

  1. Ajouter un nouveau point d' arrêt d'exception du point de vue du débogage
  2. Accéder à ses propriétés
  3. Aller au filtrage
  4. Dans "Restreindre aux emplacements sélectionnés", cliquez sur " Ajouter une classe "
  5. Ajouter java.util.concurrent.ThreadPoolExecutor
  6. Décochez la case , ce qui signifie qu'ils seront ignorés
EngineerBetter_DJ
la source
1
Je n'arrive pas à le faire fonctionner avec Tomcat 7 et Eclipse / STS 3.4.0. Y a-t-il d'autres paramètres nécessaires? Ce point d'arrêt doit-il être enregistré RuntimeException? Doit-il être activé ou désactivé? Les «emplacements capturés» et les «emplacements non capturés» devraient-ils être activés ou désactivés?
Henrik Heimbuerger
2
Il semble que le point d'arrêt d'exception doit être une java.lang.RuntimeException, doit être activé, doit être pour un emplacement non capturé uniquement et la classe java.util.concurrent.ThreadPoolExecutor ne doit pas être vérifiée.
mario
Malheureusement, sur Ubuntu 14.04, la fonction "Restreindre aux emplacements sélectionnés" n'est pas disponible pour Eclipse Luna 4.4.0.
eeezyy
2

J'ai remarqué que cela se produit souvent après avoir modifié les fichiers du serveur (jsp ou java) et STS a du mal à recharger l'application.

Cela conduit généralement à redémarrer le serveur afin de le synchroniser.

Après avoir introduit JRebel - il semble avoir disparu. Donc, je voudrais penser que c'est un problème reproductible dans STS lors du hotswapping de code en mode débogage.

En supprimant le hotswapping natif, il élimine le problème de rupture dans la classe ThreadPoolExecutor.

DaCrazyCoder
la source