web-dev-qa-db-fra.com

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

Je travaille sur mes projets habituels sur Eclipse, c'est une application J2EE, faite avec Spring, Hibernate, etc. J'utilise Tomcat 7 pour cela (pas de raison particulière, je n'exploite aucune nouvelle fonctionnalité, je voulais juste essayer ça). 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 est ThreadPoolExecutor. Il n'y a pas de trace de pile sur la console, elle s'arrête. Ensuite, si je clique sur CV, l'application 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 expliquer cela, parce que je n'utilise pas du tout ThreadPoolExecutor. Doit être quelque chose de Tomcat, Hibernate ou Spring. C'est très ennuyant parce que je dois toujours reprendre pendant le débogage.

Des indices?

javaeclipsedebuggingtomcat
206
gotch4

La trace de pile publiée indique qu'une exception RuntimeException a été rencontrée dans un thread de démon. Cela est généralement non capturé au moment de l'exécution, sauf si le développeur d'origine a capturé 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 capturées . Notez que l'exception peut être gérée plus tard, plus bas dans le cadre de la pile et peut ne pas entraîner l'arrêt du thread. Ceci serait la cause du comportement observé.

Configurer le comportement d’Eclipse est simple:
Aller à Fenêtre> Préférences> Java> Débogage et décocher Suspendre l'exécution) sur les exceptions non capturées.

286
Vineet Reynolds

Il existe une solution plus spécifique, qui empêche Eclipse d'interrompre la lecture sur RuntimeExceptions uniquement à partir d'une classe donnée.

  1. Ajouter un nouveau point d'arrêt d'exception de la perspective de débogage
  2. Aller à ses propriétés
  3. Aller à Filtrage
  4. Dans "Limiter 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
47
EngineerBetter_DJ

Ce comportement est déclenché par Tomcat lorsqu'une application Web est rechargée. Cela fait partie de Tomcat fonctionnalité "protection contre les fuites de mémoire" qui oblige (entre autres) le renouvellement de ses threads.

Ceci est maintenant corrigé depuis les versions 7.0.54 et 8.0.6 de Tomcat: https://issues.Apache.org/bugzilla/show_bug.cgi?id=56492

23
slaurent

J'ai remarqué que cela se produit souvent après la modification des fichiers du serveur (jsp ou Java) et que STS a des difficultés à recharger l'application.

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

Après avoir présenté JRebel - il semble être parti. Donc, j'aimerais penser qu'il s'agit d'un problème reproductible dans STS lors de l'échange de code en mode débogage.

En supprimant l’échange à chaud natif, il élimine le problème de la rupture de la classe ThreadPoolExecutor.

2
DaCrazyCoder