El depurador de Eclipse siempre bloquea ThreadPoolExecutor sin ninguna excepción obvia, ¿por qué?

Estoy trabajando en mis proyectos habituales en Eclipse, es una aplicación J2EE, hecha con Spring, Hibernate, etc. Estoy usando Tomcat 7 para esto (sin ninguna razón en particular, no exploto ninguna característica nueva, solo quería probar eso). Cada vez que depuro mi aplicación, sucede que el depurador de Eclipse aparece como si hubiera alcanzado un punto de interrupción, pero no es el caso, de hecho, se detiene en un archivo fuente Java ThreadPoolExecutor. No hay rastro de pila en la consola, simplemente se detiene. Luego, si hago clic en reanudar, continúa y la aplicación funciona perfectamente. Esto es lo que se muestra en la ventana del depurador:

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

Realmente no puedo explicar esto, porque no estoy usando ThreadPoolExecutor en absoluto. Debe ser algo de Tomcat, Hibernate o Spring. Es muy molesto porque siempre tengo que reanudar durante la depuración.

¿Alguna pista?

El seguimiento de pila publicado indica que se encontró una RuntimeException en un hilo Daemon. Esto normalmente no se detecta en tiempo de ejecución, a menos que el desarrollador original haya detectado y manejado la excepción.

Por lo general, el depurador en Eclipse está configurado para suspender la ejecución en el lugar donde se produjo la excepción, en todas las excepciones no detectadas . Tenga en cuenta que la excepción podría manejarse más tarde, más abajo en el marco de la pila y podría no dar lugar a la terminación del hilo. Esto sería causa del comportamiento observado.

Configurar el comportamiento de Eclipse es sencillo:
vaya a Ventana > Preferencias > Java > Depurar y desmarque Suspender ejecución en excepciones no detectadas .

Hay una solución más específica, que evita que Eclipse se rompa RuntimeExceptionsolo en una clase dada.

1. Agregar un nuevo punto de interrupción de excepción de desde la perspectiva de depuración
2. Ir a sus propiedades
3. Ir a filtrado
4. En "Restringir a las ubicaciones seleccionadas", haga clic en " Agregar clase "
5. Añadir java.util.concurrent.ThreadPoolExecutor
6. Desmarca la casilla de verificación , lo que significa que se ignorarán

Tomcat desencadena este comportamiento cuando se vuelve a cargar una aplicación web. Es parte de la función de "protección de pérdida de memoria" de tomcat que (entre otras cosas) fuerza la renovación de sus hilos.

Esto ahora se corrige desde las versiones 7.0.54 y 8.0.6 de tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

Me di cuenta de que esto ocurre a menudo después de modificar los archivos del servidor (jsp o java) y STS tiene problemas para volver a cargar la aplicación.

Esto generalmente lleva a reiniciar el servidor para que sincronice los cambios.

Después de presentar JRebel, parece que se ha ido. Por lo tanto, me gustaría pensar que es un problema reproducible en STS cuando se utiliza el código hotswapping en modo de depuración.

Al eliminar el hotswapping nativo, elimina el problema de que se rompa dentro de la clase ThreadPoolExecutor.