Não existe esse recurso para o Tomcat.
Lembre-se de que o Tomcat é um servidor de aplicativos e não um servidor da web, e precisa carregar as coisas ao iniciar e, talvez, desligar tudo muito bem durante o desligamento.
Em uma pilha LAMP básica, pelo menos com nossos servidores RHEL5 / 6, podemos aplicar atualizações contínuas de código em nosso sistema de gerenciamento de documentos em servidores Web com balanceamento de carga sem eliminar as conexões dos usuários (e possivelmente downloads de documentos) usando apachectl graceful e apachectl graceful-stop . Estamos migrando para um aplicativo baseado no servidor da web Tomcat e gostaríamos de ter esse tipo de capacidade com nosso novo sistema, mas não consigo encontrar qualquer tipo de funcionalidade equivalente com tomcat6. Existe tal capacidade com o tomcat6?
Resposta curta
Se você tiver instâncias do tomcat carregadas de carga e seu balanceador de carga oferecer suporte a sessões fixas e configurações ativas, você poderá obter o tipo de atualizações contínuas e rolantes sobre as quais está falando (até certo ponto) girando as instâncias do tomcat 1 por 1.
Resposta longa (a)
Com relação às outras respostas, a descrição correta do tomcat como um servidor de aplicativos vs httpd e os problemas associados, na verdade, existem várias maneiras de obter o que você deseja, que é uma reinicialização transparente do usuário final.
Dado que o tomcat frequentemente leva 30 segundos ou mais, dependendo de quão monstruoso e inchado seu aplicativo é implementar a partir do frio, geralmente é útil poder fazer isso de maneira transparente.
Um bônus adicional desse método que explicarei é que é reconfortante poder verificar o novo aplicativo na produção antes de colocá-lo em funcionamento para seus clientes.
Então ... reinício tranquilo do apache aconselha seus filhos a sair após a conclusão da solicitação atual e os substitui por novos processos / threads gerados que releiam o novo arquivo de configuração. Portanto, conexões de longa duração podem terminar o download enquanto novas solicitações obtêm o novo conteúdo. Existem efetivamente duas versões do aplicativo em execução durante a transição de reinicialização gradual gerenciada pelo apache, o antigo e o novo.
Infelizmente, com o tomcat se autodeploy = true estiver definido, qualquer alteração para os arquivos de configuração ou conteúdo de guerra causa uma reimplantação bastante deselegante do Contexto e eu diria que o contêiner de web Catalina aguarda por algum tempo especificado, antes de eliminar todos os encadeamentos e solicitações pendentes. Não é muito transparente, e você acaba recebendo erros horríveis de 500 até que o aplicativo esteja de pé: - (
Assim, para permitir a experiência transparente do usuário final, você precisará ter duas versões do seu aplicativo em execução ao mesmo tempo por um curto período, uma para as conexões antigas e outra para as novas. (Há uma série de ressalvas para essas abordagens que abordarei abaixo ...)
O modo mais simples é ter um balanceador de carga front-end como apache, haproxy ou Cisco CSM com 2 ou mais instâncias de tomcat - em que o balanceador de carga suporta sessões fixas e balanceador de carga quente implantação de configuração.
por exemplo, tomcat1, tomcat2 e balancer
Observe que é o nível de preferência do nó alterar em vez de, o nó soltar permitirá que o balanceador de carga gerencie a transição das conexões para o novo aplicativo da web.
Obviamente, se você tiver apenas 1 servidor e, portanto, apenas 1 tomcat, poderá criar algo semelhante, mas isso requer alguns nomes inteligentes para sua aplicação web. Eu nunca tive que implantar em produção em 1 tomcat, mas eu faria isso com 2 versões do meu aplicativo web com diferentes nomes de guerra e caminhos de doc instalados no mesmo tomcat6 assim;
/var/lib/tomcat6/webapps/mywebapp_0_1.war => http://localhost:8080/mywebapp_0_1
/var/lib/tomcat6/webapps/mywebapp_0_2.war => http://localhost:8080/mywebapp_0_2
E torne a alteração transparente usando o mod_proxy ou o haproxy do apache para migrar as conexões entre os dois aplicativos normalmente.
ou seja, eu teria o apache httpd AND tomcat6 instalado junto na mesma caixa, com o httpd mod_proxy apontando assim;
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
<Location /balancer-manager>
SetHandler balancer-manager
</Location>
<Proxy balancer://cluster>
BalancerMember http://localhost:8080/webapp_0_1
BalancerMember http://localhost:8080/webapp_0_2
</Proxy>
<Location />
ProxyPass balancer://cluster/webapp stickysession=JSESSIONID
</Location>
Caveat , se você tiver que atualizar seus esquemas de banco de dados, a menos que você queira começar a fazer alguns nomes malucos e links sh * t com seus bancos de dados como database_0_1, então você terá que sugar algum tempo de inatividade.
Se seus usuários tiverem sessões muito longas, o tomcat6 suporta agrupamento de sessões usando um variedade de backends
Tags tomcat