Discussion :

[jreeman]

Bonjour,

quelquefois je n'arrive pas à arrêter le serveur tomcat en faisant

/etc/init.d/tomcat stop

(de mémoire cette commande me renvoie une bind exception et) en faisant un "ps -edf" je me rends compte que le process est toujours là.

Ce problème m'est arrivé en fait plusieurs fois (mais je ne m'en rends jamais compte tout suite,malheureusement), j'ai peut être une explication : peut-être ais-je arrêté à un moment ou à un autre le serveur tomcat et je l'ai redémarré trop vite avant que le processus précédent ne soit réellement arrêté.

Effectivement j'ai remarqué qu'après le tomcat stop le process tomcat, lui, est encore là quelques secondes ou millisecondes (ce que je trouve moyen de la part de tomcat d'ailleurs).

Avez-vous des retours d'expériences sur ce genre de problème ?

[tchize_]

alors, le stop conciste à se connecter au port de maintenance de tomcat et à lui envoyer l'instruction "stop". De là tomcat décharge toutes ses webapps une à une, et cloture tout ses thread. Ensuite, la jvm devrait s'arreter. La commande de stop, en elle meme retourn imédiatement. Le process d'arret des webapp dépend de celles-ci, et peux varier de quelques secondes à plusieurs minutes suivant la taille des webapps. Si, après çà, tomcat tourne encore, c'est souvent que la webapp a d'elle meme instancié des threads (pas bien mais on a pas toujours le choix) et ne les a pas cloturé. Un jvm ne s'arrette pas d'elle même tant que tout ses threads ne sont pas morts.

Ce qui se passe parfios c'est qu'un tomcat se bloque (faute à la webapp) et ne réagisse dont plus au stop. Faut alors passer par kill.

[jreeman]

ok merci pour cette explication.

Pour les threads tout à fait cela ne métonne pas, on utilise un thread pool executor en interne et il y a aussi jboss cache qui a ses propres threads, du coup j'aimerais savoir qui n'arrête pas ses threads correctement. Vous rapelleriez vous quelle commande permet d'avoir un instantané des threads en cours dans la jvm ?

[tchize_]

kill -3 sous unix

[jreeman]

humm je pensais pas à cela, je vais essayer de me renseigner (de mémoire c'est kill -sig ou java -sig).

[gexian]

Par expérience, j'ai vu qu'il fallait laisser le temps à tomcat de s'arrêter, tant qu'il est dans les processus (un petit ps -aux | grep tomcat pour regarder) il ne faut surtout pas lancer le start.

Après y a toujours moyen de bidouiller le script /etc/init.d/tomcat, mais là ça deviens plus subtile. Sur un script de déploiement, j'ai du rajouter un sleep de près de 2mn pour le stop et le start pour éviter les problèmes.

[jreeman]

Par expérience, j'ai vu qu'il fallait laisser le temps à tomcat de s'arrêter, tant qu'il est dans les processus (un petit ps -aux | grep tomcat pour regarder) il ne faut surtout pas lancer le start.

Après y a toujours moyen de bidouiller le script /etc/init.d/tomcat, mais là ça deviens plus subtile. Sur un script de déploiement, j'ai du rajouter un sleep de près de 2mn pour le stop et le start pour éviter les problèmes.

Oui exact en fait les thread dans les pool de java.util.concurrent ont un temps apellé keepAliveTime qui est le temps pendant lequel même si le thread n'est pas utilisé il est gardé en vie. Donc si l'application n'apelle pas le shutdown sur le pool il n'y a pas d'autre choix que d'attendre si il y avait encore de l'activité dans les n derniers instants avant l'appel à tomcat stop. Personnellement, j'ai mis cette valeur à 20 secondes (je n'apelle pas shutdown, c'est un choix). La valeur par défaut c'est 60 secondes je crois.

Mais je recherche tooujours cette commande magique qui me permettra la prochaine fois que ca arrive (si ca arrive) de voir les threads existants dans la jvm.

[tchize_]

je te l'ai donnée la commande :/ Y a pas 36.000 commande sous linux / unix, faut envoyer le signal 3 à la jvm, elle fait alors un Thread dump dans stdout. (Soit donc au final dans catalina.out)

[jreeman]

oui désolé, tu as raison. et c'est bien cela ca se retrouvait dans le catalina.out.
(ce qui m'a trompé c'est que je l'avais taper comme ca "kill -SIGQUIT pid" ce qui est exactement pareil).