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 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?

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 .

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

Ce comportement est déclenché par tomcat lorsqu'une webapp est rechargée. Cela fait partie de la fonctionnalité Tomcat de «protection contre les fuites de mémoire» qui force (entre autres) le renouvellement de ses threads.

Ce problème est désormais résolu à partir des versions 7.0.54 et 8.0.6 de tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

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.