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 ThreadPoolExecutor
nada. Deve ser algo do Tomcat, Hibernate ou Spring. É muito chato porque eu sempre tenho que continuar durante a depuração.
Alguma pista?
Respostas:
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 .
fonte
Existe uma solução mais específica, que evita que o Eclipse seja
RuntimeException
ativado somente após uma determinada classe.java.util.concurrent.ThreadPoolExecutor
fonte
RuntimeException
? Ele precisa ser ativado ou desativado? 'Locais capturados' e 'Locais não capturados' devem estar ativados ou desativados?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
fonte
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.
fonte