Version imprimable
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 :)
Ca ne doit pas toujours le cas, il faut voir les paramètres autodeploy de la configuration du server.xml
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)
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 :)
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 :
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).Code:
2
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 ?
qu'en prod il vaut mieux planifier une mise a jou incluant un arret de quelques minutes du tomcat :lol:
oui mais ça impliquerait de prévenir tous les clients, ce qui n'est pas chose aisée pour nous...Citation:
Envoyé par tchize_
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 ?
que tu redémarre tomcat ou uniquement le contexte, les utilisateur de ce contexte vont avoir une interruption de service. Si service continu il doit y avoir, je suggère plutot dans ce cas de dédoubler les tomcat avec un serveur web en front end. Ainsi t'arrete et met à jour le premier, puis le deuxième ;)
Comme déjà expliqué, tu peux te contenter de ne redémarrer que le contexte, mais tu finira au bout de quelques cycle avec le problème de la mémoire (permgen) si il y a la moindre libraire dans ta webapp pas concue pour aller dans une webapp.
Merci à tous pour vos réponses.
J'ai une question stupide :
pour faire tourner un web service (côté serveur) écrit en Java (avec Axis) sous windows, faudra-t'il aussi tomcat ?
Actuellement j'ai mon web service qui tourne sous linux, avec Tomcat et Axis.
Et je me demandais comment faire sous windows. A mon avis ce sera la même chose mais j'aimerais être sûre.
Merci à vous
tomcat ou n'importe quel autre conteneur webapp ;) (jboss, jonas, websphere, etc)
tchize_ : Pour les problèmes de memory leak dans le permgen, regarde dans Tomcat 6.0.24, il y a un listener qui fait le ménage.
Dans tous les cas, l'option reloadable n'assure aucune continuité de service, il y a toujours le problème des sessions.
merci pour l'info. Reste à voir si le fix est porté sous jboss :mouarf:. 5 ans qu'on l'attendais nous :calim2:
Concernant les sessions, si t'as bien fait gaffe à ne mettre que des données sérializables dans la session, ca ne devrais pas poser de soucis, tomcat sérialize puis désérialize les sessions ;)
Pour JBoss, ça m'étonnerait qu'on l'ait avant la v6.
Pour la sérialisation, encore faut-il que les modifs n'impactent pas les objets sérialisés...
A suivre, sur le même sujet : ZeroTurnaround LiveRebel.