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


209

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?


1
@ AmosM.Carpenter, ¿no es Java EE, no JEE? Incluso su propio enlace parece sugerir de modo
EIS

Respuestas:


290

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 .



55
He presentado el error Eclipse 384073 sobre esto, ya que esencialmente hace que esta opción sea inutilizable al depurar aplicaciones web.
Daniel Serodio

9
Desactivar la "Suspender la ejecución en excepciones no detectadas" en Eclipse es una mala solución: ¿qué sucede si desea que Eclipse se suspenda en excepciones reales no detectadas, por ejemplo, originadas en su propio código? Me parece que esto es un error en Tomcat ...

3
@Luis: ¡Me preguntaba lo mismo! Según bugs.eclipse.org/bugs/show_bug.cgi?id=384073#c4 , uno puede: deshabilitar los puntos de interrupción globales, crear un nuevo punto de interrupción en java.lang.Exception y aplicar un filtro exclusivo contra este punto de interrupción recién creado.
rektide el

3
@Daniel ... Tal vez sea mejor presentar un problema con el equipo de Tomcat. Creo que este comportamiento es nuevo en Tomcat 7 ... Eclipse hace lo que se supone que debe hacer ... (nunca pensé que terminaría defendiendo a Eclipse algún día ... :)
Stijn de Witt

48

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

1
Parece que no puedo hacer que funcione con Tomcat 7 y Eclipse / STS 3.4.0. ¿Hay alguna otra configuración necesaria? ¿Debería registrarse este punto de interrupción RuntimeException? ¿Tiene que estar habilitado o deshabilitado? ¿Deben estar activadas o desactivadas las 'ubicaciones capturadas' y las 'ubicaciones no capturadas'?
Henrik Heimbuerger

2
Parece que el punto de interrupción de excepción debe ser java.lang.RuntimeException, debe estar habilitado, debe ser solo para la ubicación no capturada y no debe tener marcada la clase java.util.concurrent.ThreadPoolExecutor.
mario

Desafortunadamente en Ubuntu 14.04 el "Restringir a las ubicaciones seleccionadas" no está disponible, para Eclipse Luna 4.4.0.
eeezyy


2

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.