Tomcat 7.0.22 Quebras de serviço do Windows com atualização do JRE

Question

Se a atualização do JRE for executada sem primeiro interromper manualmente o serviço do Tomcat, o Tomcat não será mais iniciado após a próxima vez que for interrompido. Isso geralmente acontece após a reinicialização por solicitação do instalador do JRE.

Para reproduzir o erro

• Instale o Tomcat 7 mais recente como um serviço do Windows com o Java 6 u29 instalado. O Tomcat deve funcionar bem.
• Atualize para o Java 6u31 sem primeiro interromper o serviço do Tomcat . Java requer uma reinicialização do servidor e, após a reinicialização, o serviço Tomcat não será mais iniciado.

Registros após a reinicialização

Tomcat 7 stdout

2012-04-03 12:25:02 Commons Daemon procrun stdout initialized 
2012-04-03 12:42:25 Commons Daemon procrun stdout initialized 
Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object 

Última parte do stderr do Tomcat7 (a única linha após a atualização e reinicialização do Java)

2012-04-03 12:42:25 Commons Daemon procrun stderr initialized

    

Answer 1

Observamos isso com um aplicativo Java de longa execução (mas não o Tomcat) que é executado como um serviço do Windows. Criamos isso como um serviço do Windows com o mecanismo "procrun" no Apache Commons Daemon, que é o mesmo que o serviço Tomcat do Windows funciona.

A partir de sugestões de outros relatórios, parece que o processo de atualização do Java move / renomeia arquivos como parte da atualização para a nova versão. Pode haver uma ou duas renomeações a serem feitas quando a instalação for concluída, e essas renomeações devem acontecer após uma reinicialização. Mas se houver um aplicativo Java de longa execução em execução ao mesmo tempo em que a atualização estiver ocorrendo, esse aplicativo terá várias libs e exe Java (como o jre.exe principal) bloqueados e a atualização do Java falhará.

Um sintoma disso é abrir uma janela de comando e digitar "java -version". Se você receber o erro noclassdeffound para java / lang / Object, é bem provável que a combinação de uma atualização do JDK com um aplicativo Java de longa duração o tenha deixado com um JDK / JRE corrompido.

Encontramos duas soluções alternativas: (1) reinstalar o aplicativo; (2) reinstale o Java. (1) geralmente funciona para nós porque temos um instalador para o aplicativo que também instalará uma versão limpa do Java, se necessário. Às vezes, até mesmo isso falha, com a mensagem "O arquivo jar 'reach-stream-installer-izpack.jar' não pôde ser executado." (O IzPack é a ferramenta de instalação automatizada que usamos). Neste caso, voltamos para (2).

Nenhuma solução alternativa é muito boa. É uma pena que o recurso de atualização automática do JDK fornecido pelo Java viole nosso aplicativo.

Você fez algum progresso com isso desde a postagem original?