Discussion :

[_LittleFlea_]

Bonjour à tous,

j'ai remarqué que lorsqu'on modifie un fichier .class dans le répertoire WEB-INF/classes d'une appli, il fallait redémarrer tomcat pour qu'ils prennent en compte les modifs.
Dans un environnement de production, je pense que ceci peut être un problème, non ? D'où ma question, existe-t'il un moyen pour que les modifs soient prises en compte sans avoir à redémarrer le serveur ?

Merci à vous pour vos réponses

[MrEddy]

Ca ne doit pas toujours le cas, il faut voir les paramètres autodeploy de la configuration du server.xml

[Jidefix]

Bonjour,
sur mon serveur, les fichiers .jsp et class. sont rafraichis automatiquement si je les modifie, ça doit dépendre effectivement des paramètres du server.xml
En revanche il arrive que le rafraichissement des .class bloque le serveur (plus aucune servlet ne réagit).
En général je m'en sors en faisant ctrl+C dans la console tomcat, mais des fois en plus de débloquer Tomcat ça le coupe carrément.

Bref je trouve pas ça hyper fiable et si ça peut bien dépanner, c'est quand même pas une pratique que je recommande en production (je crois que sous JBoss par exemple c'était une cause de OutOfMemory: PermGenSpace, ça m'étonnerai pas que ça fasse la même chose sous Tomcat)

[tchize_]

si les webapp sont pas propre, il arrive que catalina (le moteur derrière tomcat) ne sache pas nettoyer le classloader de la webapp, résultat les classloader s'accumulent au fur et à mesure jusqu'à atteindre le remplissage du permgen. Sinon, théoriquement, pas besoin de redémarrer tomcat, mais il faut redémarrer la webapplication concernée (en autodeploy, elle redémarre d'elle même). En pratique, si tu utilise du hibernate ou autre librairie basée sur cglib, tu va manger du permgen si tu fais ça

[_LittleFlea_]

il me semble avoir trouvé une solution :

dans l'appli qui doit être rechargée au cas où un .class a été modifié (axis dans mon cas, je fais des web services), dans un répertoire META-INF, je crée un fichier context.xml qui contient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<?xml version="1.0" encoding="ISO-8859-1"?>
<Context path="/axis" docBase="axis" reloadable="true" />

et ça recharge le contexte dès qu'un class a été modifié. Mais je crois que c'est un process qui tourne en boucle et ce n'est pas terrible (enfin en dév ça va).

Sinon quand ce sera en prod je pensais recharger le context de mon appli via le gestionnaire des application Tomcat, à la main donc, sachant que ce sera fait que lors d'une nouvelle mise en production, donc assez rarement.

qu'en pensez-vous ?

[tchize_]

qu'en prod il vaut mieux planifier une mise a jou incluant un arret de quelques minutes du tomcat

[_LittleFlea_]

qu'en prod il vaut mieux planifier une mise a jou incluant un arret de quelques minutes du tomcat

oui mais ça impliquerait de prévenir tous les clients, ce qui n'est pas chose aisée pour nous...

je ne peux pas recharger le contexte manuellement sans arrêter tomcat ?? quel serait le problème ?

De plus, peut être que je me trompe, mais j'ai l'impression que tomcat recharge le contexte uniquement lorsqu'il a terminé les traitements qu'il était eventuellement en train de faire. Et dans ce cas tout va bien, non ? Me trompe-je ?