apagado de Tomcat MUY lento después de llamar a shutdown.sh?

Question

Mi situación es así:

Cada vez antes de cargar el archivo war a la carpeta de la aplicación web, dejo Tomcat llamando al sh shutdown.sh. Solía ​​tomar unos 30 segundos para un apagado total. Pero ahora ya no funciona bien.

En realidad, funcionó un poco, porque cuando accedo a la aplicación desde la página web arroja el error 503 (Bajo Mantenimiento). Pero cuando uso ps aux | grep tomcat para verificar, el proceso de tomcat aún está allí. Y estará allí por alrededor de 5 a 10 minutos.

Entiendo que puede necesitar tomar más tiempo para completar todas las tareas, pero es demasiado lento (5-10 minutos) antes de que se detenga por completo. No entiendo por qué sucede esto, pero debe haber alguna razón. Quizás haya algo que ver con el código o con el nuevo script de implementación que utilizamos recientemente. Simplemente no tengo ni idea de dónde comprobarlo.

Esto es importante para nuestro equipo porque estamos utilizando el "despliegue automático", en el cual usamos un script para autoensamblar el archivo war, cargarlo e implementarlo en un momento específico. Si iniciamos una nueva instancia de tomcat antes de que el anterior se cierre con éxito, se quedará allí para siempre, y limpiar la tarea con "kill -9" es desalentador.

¿Hay alguien que haya experimentado este problema? Cualquier pista sería apreciada.

Answer 1

Hoàng Long -

Gracias por la actualización.

1) El hecho de que usted ve a sus puestos de trabajo de cuarzo funcionando, y el mensaje de error, son significativos:

GRAVES: La aplicación web [/ proyecto] parece haber comenzado una hilo llamado [Recurso Destructor en BasicResourcePool.close()] pero no ha podido detenerlo en . Esto es muy probable que cree una pérdida de memoria.

2) Una sugerencia es de configuración:

http://forum.springsource.org/showthread.php?17833-Spring-Quartz-Tomcat-no-shutdown

I tenían el mismo problema. Lo arreglé agregando destroy-method="destroy" a la definición de SchedulerFactoryBean. De esta manera, el resorte cierra el planificador cuando se detiene la aplicación .

3) Otra sugerencia es añadir un detector de apagado:

http://forums.terracotta.org/forums/posts/list/15/4341.page

Usando un oyente contexto y la introducción de un tiempo de espera en la parada resuelve el problema para mí. Sólo tiene que esperar un segundo después de cerrar:

public void contextDestroyed(ServletContextEvent sce) { 
    try { 
     factory.getScheduler().shutdown(); 
     Thread.sleep(1000); 

Answer 2

Si esto es algo que místicamente empezó a suceder en los últimos días, tal vez se está ejecutando en el segundo error de salto de Linux?Para obtener más información, consulte

https://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second

https://access.redhat.com/knowledge/articles/15145

http://pedroalves-bi.blogspot.fi/2012/07/java-leap-second-bug-how-to-fix-your.html