O depurador do Eclipse sempre bloqueia no ThreadPoolExecutor sem nenhuma exceção óbvia, por quê?

Estou trabalhando nos meus projetos habituais no Eclipse, é um aplicativo J2EE, feito com Spring, Hibernate e assim por diante. Estou usando o Tomcat 7 por isso (sem motivo específico, não exploro nenhum novo recurso, só queria tentar isso). Toda vez que depuro meu aplicativo, acontece que o depurador do Eclipse aparece como se tivesse atingido um ponto de interrupção, mas não é o caso, na verdade, ele para em um arquivo de origem Java ThreadPoolExecutor. Não há rastreamento de pilha no console, apenas para. Então, se eu clicar em continuar, ele continuará e o aplicativo funcionará perfeitamente. Isto é o que mostra na janela do depurador:

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

Realmente não posso explicar isso, porque não estou usando ThreadPoolExecutornada. Deve ser algo do Tomcat, Hibernate ou Spring. É muito chato porque eu sempre tenho que continuar durante a depuração.

Alguma pista?

O rastreamento de pilha publicado indica que uma RuntimeException foi encontrada em um encadeamento do Daemon. Isso normalmente não é capturado em tempo de execução, a menos que o desenvolvedor original tenha capturado e manipulado a exceção.

Normalmente, o depurador no Eclipse é configurado para suspender a execução no local em que a exceção foi lançada, em todas as exceções não capturadas . Observe que a exceção pode ser tratada posteriormente, mais abaixo no quadro da pilha e pode não levar ao término do encadeamento. Isso seria causa do comportamento observado.

A configuração do comportamento do Eclipse é simples:
Vá para Janela > Preferências > Java > Depurar e desmarque Suspender execução em exceções não capturadas .

Existe uma solução mais específica, que evita que o Eclipse seja RuntimeExceptionativado somente após uma determinada classe.

1. Adicionar um novo ponto de interrupção de exceção na perspectiva Depuração
2. Vá para o seu propriedades
3. Vamos para Filtragem
4. Em "Restringir aos locais selecionados", clique em " Adicionar classe "
5. Adicionar java.util.concurrent.ThreadPoolExecutor
6. Desmarque a caixa de seleção , o que significa que eles serão ignorados

Esse comportamento é acionado pelo tomcat quando um aplicativo da web é recarregado. Faz parte do recurso "proteção contra vazamento de memória" do tomcat que (entre outras coisas) força a renovação de seus threads.

Agora isso foi corrigido das versões 7.0.54 e 8.0.6 do tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

Percebi que isso geralmente ocorre após a modificação dos arquivos do servidor (jsp ou java) e o STS tem problemas ao recarregar o aplicativo.

Isso geralmente leva à reinicialização do servidor para que ele sincronize as alterações.

Após a introdução do JRebel - parece ter desaparecido. Então, eu gostaria de pensar que é um problema reproduzível no STS ao codificar hotswapping no modo de depuração.

Ao remover o hotswapping nativo, ele elimina o problema com ele dentro da classe ThreadPoolExecutor.