Il debugger di Eclipse si blocca sempre su ThreadPoolExecutor senza alcuna ovvia eccezione, perché?

Sto lavorando ai miei soliti progetti su Eclipse, è un'applicazione J2EE, realizzata con Spring, Hibernate e così via. Sto usando Tomcat 7 per questo (nessun motivo particolare, non utilizzo nessuna nuova funzionalità, volevo solo provarlo). Ogni volta che eseguo il debug della mia applicazione, capita che il debugger di Eclipse esploda come se avesse raggiunto un punto di interruzione, ma non è così, in realtà si ferma su un file sorgente Java che lo è ThreadPoolExecutor. Non c'è traccia dello stack sulla console, si ferma. Quindi, se faccio clic su Riprendi, continua e l'app funziona perfettamente. Questo è ciò che mostra nella finestra del debugger:

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

Non riesco davvero a spiegarlo, perché non lo sto usando ThreadPoolExecutoraffatto. Deve essere qualcosa di Tomcat, Hibernate o Spring. È molto fastidioso perché devo sempre riprendere durante il debug.

Qualche indizio?

La traccia dello stack pubblicata indica che è stata rilevata una RuntimeException in un thread Daemon. In genere, questo non viene rilevato durante l'esecuzione, a meno che lo sviluppatore originale non abbia rilevato e gestito l'eccezione.

In genere, il debugger in Eclipse è configurato per sospendere l'esecuzione nella posizione in cui è stata generata l'eccezione, su tutte le eccezioni non rilevate . Si noti che l'eccezione potrebbe essere gestita in un secondo momento, più in basso nel frame dello stack e potrebbe non portare alla conclusione del thread. Questa sarebbe la causa del comportamento osservato.

La configurazione del comportamento di Eclipse è semplice:
vai su Finestra > Preferenze > Java > Debug e deseleziona Sospendi esecuzione su eccezioni non rilevate .

C'è una soluzione più specifica, che impedisce che Eclipse si rompa su RuntimeExceptionlanciati solo da una determinata classe.

1. Aggiungi un nuovo punto di interruzione delle eccezioni dalla prospettiva Debug
2. Vai alle sue proprietà
3. Vai a Filtro
4. In "Limita a località selezionate", fai clic su " Aggiungi classe "
5. Inserisci java.util.concurrent.ThreadPoolExecutor
6. Deseleziona la casella di controllo , il che significa che verranno ignorati

Questo comportamento viene attivato da Tomcat quando viene ricaricata una webapp. Fa parte della funzionalità Tomcat di "protezione da perdita di memoria" che (tra le altre cose) forza il rinnovo dei suoi thread.

Questo è stato risolto dalle versioni 7.0.54 e 8.0.6 di tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

Ho notato che ciò si verifica spesso dopo aver modificato i file del server (jsp o java) e che STS ha difficoltà a ricaricare l'applicazione.

Questo di solito porta al riavvio del server per ottenerlo per sincronizzare le modifiche.

Dopo aver introdotto JRebel, sembra essere andato via. Quindi, vorrei pensare che sia un problema riproducibile in STS quando si esegue l'hotswapping del codice in modalità debug.

Rimuovendo l'hotswapping nativo, elimina il problema che si interrompe all'interno della classe ThreadPoolExecutor.