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

Question

Je suis en train de travailler sur mes projets d'habitude sur Eclipse, c'est une application J2EE, faite avec Spring, Hibernate et ainsi de suite. J'utilise Tomcat 7 (pas de raison particulière, je n'ai pas exploiter toute nouvelle fonctionnalité, je voulais juste essayer). Chaque fois que je debug de mon application, il arrive que débogueur Eclipse sort comme il a atteint un point d'arrêt, mais il n'est pas le cas, en fait il s'arrête sur un fichier source de Java c'est - ThreadPoolExecutor. Il n'y a pas de trace de la pile sur la console, il s'arrête juste. Ensuite si je clique sur le curriculum vitae, il passe et l'application fonctionne parfaitement. C'est ce que montre, 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 pas vraiment l'expliquer, parce que je ne suis pas en utilisant ThreadPoolExecutor . Doit être quelque chose de Tomcat, Hibernate ou au Printemps. C'est très ennuyeux parce que j'ai toujours à reprendre au cours de débogage.

Des indices?

Answer 1

Posté le trace de la pile indique qu'une RuntimeException a été rencontrée dans un fil de Démon. C'est typiquement non interceptée lors de l'exécution, à moins que le développeur d'origine attrapé et gérée à l'exception.

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

Configurer le comportement de l'Éclipse est simple - dans les Préférences de la boîte de Dialogue, le Débogage volet en vertu de Java dans la hiérarchie de l'arbre, a l'option intitulée "Suspendre l'exécution sur les exceptions non traitées", qui peut être désactivée.

Answer 2

Il y a une solution spécifique, ce qui empêche l'Éclipse de rupture sur RuntimeExceptions levée uniquement à partir d'une classe donnée.

1. Ajouter une nouvelle exception point d'arrêt à partir de la perspective Débogage
2. Accédez à ses propriétés
3. Aller pour le Filtrage
4. Dans "Restreindre à l'Emplacement Sélectionné(s)", cliquez sur "Ajouter une Classe"
5. Ajouter java.util.concurrent.ThreadPoolExecutor
6. Décocher la case, ce qui signifie que ces sera ignoré

Answer 3

Ce comportement est déclenché par tomcat lorsqu’un webapp est rechargé. Il fait partie de tomcat caractéristique de « protection de fuite de mémoire » qui (entre autres) oblige le renouvellement de son fils.

Ceci est maintenant corrigé des versions 7.0.54 et 8.0.6 de tomcat : https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

Answer 4

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

Cela conduit généralement à redémarrer le serveur afin de l'obtenir pour obtenir les changements synchronisés.

Après l'introduction de JRebel - il semble avoir disparu. Donc, je voudrais croire qu'il est reproductible question dans le STS quand hotswapping code en mode de débogage.

En supprimant le natif hotswapping, il élimine le problème de rupture à l'intérieur de la ThreadPoolExecutor classe.