Problèmes dans classloaders pour l'exécution de longues processus Tomcat

Question

Nous avons organisé nos applications Web sur Tomcat 6.0.18 et expérimenté le problème suivant:

Il y a deux applications Web WebApp1 et webapp2, les deux sont même système, mais des versions différentes.

Maintenant, le problème est quand Tomcat a fonctionné pendant une semaine ou plus de temps alors parfois le système donne NoClassDefFoundError! nous avons également eu un problème étrange où le chargeur de classe de WebApp1 a chargé la classe présente dans le jar de WebApp2! Le même jar est également présent dans WebApp1 mais les versions sont différentes. Lorsque nous avons redémarré le Tomcat, tout a commencé à bien fonctionner! Notre JRE est 1.5.10

S'il vous plaît laissez-moi savoir si vous avez rencontré de tels problèmes.

Cordialement, Jatan Porecha

Answer 1

J'ai rencontré beaucoup, beaucoup de saveurs de classloader bizarreries avec Tomcat - même si vous ne touchez à aucun code classloader vous, il est très facile pour Tomcat lui-même pour produire des problèmes. Le problème le plus courant semble être le déchargement et le rechargement répétés d'un classloaders fuit webapp et finalement Tomcat out of memory. La raison la plus commune que j'ai vu pour les incompatibilités de version est que Tomcat s'assure que certaines classes et pots (faisant partie de Tomcat lui-même) devancent tous les autres dans votre classapp webapp - commons-logging semble être l'exemple le plus courant - et il est possible que les chargeurs de classe soient chargés, déchargés ou conservés quand vous ne vous y attendiez pas.

Pouvez-vous fournir plus de détails? Si le pot provient d'un tiers, il y a de fortes chances que quelqu'un ait déjà vu le problème. Si c'est votre propre jar, avez-vous votre propre code de classloader dans l'application?

Answer 2

Merci Chris pour votre réponse.

Le fichier jar fait partie du système et possède des classes communes partagées par d'autres processus.

Appelons que comutils.jar pot Ainsi, le scénario est quelque chose comme,

 
WebApp1 (ver 1) 
    | 
    |- comutils.jar (ver 1) 
     | 
     |- MailSender.class (ver 1) 


WebApp2 (ver 2) 
    | 
    |- comutils.jar (ver 2) 
     | 
     |- MailSender.class (ver 2) 

Cette classe MailSender est singleton.

Maintenant, ce qui arrive parfois, c'est que chaque fois que le code de WebApp1 appelle une méthode de MailSender après avoir récupéré son instance en utilisant la méthode getInstance, alors l'appel va à MailSender (ver 2) au lieu de ver 1 !!

Espérons que cela vous donnerait un peu d'avance.

Answer 3

Je n'ai toujours pas assez de rep pour ajouter un commentaire, je vais donc devoir poster une autre réponse. :)

Cela ressemble à quelque chose que MailSender.class est chargé dans Tomcat, pas dans chaque application Web. WebApp2 le charge en premier et cela fonctionne, même s'il est chargé dans tout Tomcat et non dans WebApp2. Lorsque WebApp1 a besoin de la classe, il la voit déjà chargée dans le parent Tomcat et n'essaie pas de charger un privé vers WebApp1. Je suggère d'abord de vérifier vos répertoires Tomcat, JRE, etc ... pour voir s'il y a une copie du jar ou de la classe dans ces chemins.Après cela, je supprimerais manuellement la classe de chacun des deux fichiers jar et redémarrer Tomcat ou les applications Web pour voir ce qui se passe - vous vous attendez à ce qu'il échoue et produire une trace de pile, et cela vous dira où votre classe est chargée et qui tente de le charger. (Par exemple, à partir du nom de la classe, il est possible que vous ayez une API mail, chargée dans la JVM Tomcat, qui charge la classe - dans Tomcat et non dans votre webapp).

Answer 4

Y a-t-il une raison particulière pour laquelle vous hébergez 2 versions du même code sur le même serveur? Avoir deux fichiers différents portant exactement le même nom, contenant des classes dans le même espace de noms et ayant des noms de classes identiques semble causer toutes sortes de problèmes (dont l'erreur humaine n'est pas la moindre).