java eclipse debugging tomcat

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



debugging tomcat (4)

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 un punto de interrupción, pero no es el caso, de hecho se detiene en un archivo de origen Java que es 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 excepción RuntimeException en un hilo Daemon. Esto normalmente no se captura en el tiempo de ejecución, a menos que el desarrollador original haya detectado y manejado la excepción.

Normalmente, el depurador en Eclipse está configurado para suspender la ejecución en la ubicación donde se produjo la excepción, en todas las excepciones no detectadas . Tenga en cuenta que la excepción puede manejarse más adelante, más abajo en el marco de la pila y puede 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 en RuntimeException s solo de una clase dada.

  1. Agregar un nuevo punto de interrupción de excepción 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. Agregue java.util.concurrent.ThreadPoolExecutor
  6. Desmarca la casilla de verificación , lo que significa que se ignorarán

He notado 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 se sincronicen 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 el código hotswapping en el modo de depuración.

Al eliminar el hotswapping nativo, elimina el problema con la ruptura dentro de la clase ThreadPoolExecutor.