6
votes

tomcat 6.0.24 Exception: impossible de charger com.mysql.jdbc.sqlerror

Mon serveur Tomcat 5 fonctionnant sur Centos fréquemment (plusieurs fois / jour) produit l'erreur suivante:

Apr 7, 2011 11:02:30 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.  Could not load com.mysql.jdbc.SQLError.  The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
        at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1370)
        at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3291)
        at com.mysql.jdbc.MysqlIO.quit(MysqlIO.java:1665)
        at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4411)
        at com.mysql.jdbc.ConnectionImpl.cleanup(ConnectionImpl.java:1315)
        at com.mysql.jdbc.ConnectionImpl.finalize(ConnectionImpl.java:2761)
        at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
        at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
        at java.lang.ref.Finalizer.access$100(Unknown Source)
        at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)


2 commentaires

Ne gardez pas la même version libérule dans le dossier lib. Essayez de garder la dernière et de retirer les autres et d'essayer.


J'ai mis à niveau comme suggéré la dernière version (5.1.15) de MySQL-Connector comme suggéré et supprimé toutes les copies plus anciennes. J'utilise Tomcat 6.0.24 plutôt que 5. Désolé pour la faute de frappe.


8 Réponses :


5
votes

L'erreur n'est pas que la classe est introuvable. Il n'est pas autorisé à charger car l'application Web a été arrêtée. Je soupçonne que cela pourrait se produire après le redémarrage de la demande Web, où elle est en panne pendant une courte période. Ensuite, certains finaliser () dans le code essaient probablement de faire du nettoyage trop tard. Que ce soit ou non dans votre code ou le pilote MySQL, je ne peux pas dire. Vous ne devez certainement avoir qu'une version d'un pot dans un répertoire à la fois. Vous voudrez peut-être la mettre à niveau vers le dernier (5.1.15 en ce moment) au cas où quelque chose a été corrigé qui pourrait vous affecter.


0 commentaires

1
votes

Les versions plus récentes de Tomcat exigent de mettre des pots de pilote JDBC dans le répertoire Tomcat / Lib, et non de votre Web-Inf. Et il ne devrait s'agir que d'une version dans ce répertoire - la version que vous souhaitez utiliser - et non d'autres.

Puisque vous utilisez Tomcat 5, je vous recommande de mettre le pot dans votre répertoire serveur / lib.

Je ne sais pas si c'est la cause première de votre problème, mais ça vaut la peine d'essayer.


0 commentaires

0
votes

Vous pouvez vérifier l'ordre des répertoires dans la classe de classe. Une fois deux versions d'un fichier JAR: une dans le répertoire de travail et une autre dans le répertoire Extensions Java. L'ordre de la classe de classe était: Vérifiez d'abord le répertoire Extensions Eclipse, puis le répertoire de travail. Une fois qu'il a trouvé une version du pot dans le répertoire Extensions, elle n'a pas continué à rechercher celui que je spécifiais dans le répertoire de travail. La commande compte dans la classe de classe.


0 commentaires

0
votes

Où est votre pool de connexion JDBC configuré? Est-ce dans le JNDI (Conf / Server.XML de Tomcat) ou directement dans votre application? Est l'une de vos applications Web non renvoyées / redéployées lorsque ce message apparaît?

du code StackTrace et source de mysqlio.java et webappClassloader.java je devinerais que:

  • L'une des webapps est autorisé - basé sur le code dans WebAppClassloader:

    // Log Accès au chargeur de classes arrêté

    si (! a commencé) { essayer { jeter de nouvelles exceptions illégales (); } Catch (illegalStateException E) { log.info (sm.getstring ("webappClassLoader.sopped", nom), e); } }

  • Vos connexions JDBC ne sont pas nettoyées correctement lors de l'arrêt de l'application Web (votre servletContextListener.ContextDestroyed doit faire ce paramètre ou par exemple de méthode de détrituellement de haricot de printemps)

  • Certaines des classes utilisées par MySQL Code pilote ont été déchargées par GC
  • Ces connexions sont éligibles de GC lors de l'arrêt de votre application, mais GC découvre que la méthode de la finalisation de la connexion MySQL est remplie afin qu'elle l'exécute
  • Lorsque cette méthode finale est exécutée, il nécessite une classe qui doit être chargée. Le chargeur de classe de Tomcat de votre application Web arrêtée le détecte et indique qu'il ne devrait y avoir aucune autre classe chargée par une application Web arrêtée.

    Ma solution à votre problème serait de vérifier comment votre pool de connexion JDBC est nettoyé lors de l'arrêt de l'application Web et assurez-vous que le pool est également explicitement arrêté.


0 commentaires

0
votes

Vous êtes le plus probablement USIGN Connection de la mise en commun de votre application qui vérifie la connectivité de la base de données.


0 commentaires

2
votes

Utilisez une seule version du fichier JAR dans Web-Inf / Lib . Mieux vaut utiliser la dernière version de mysql-connecteur-java 5.1.26 .


0 commentaires

0
votes

Je pense que vous devez utiliser le mécanisme de mise en commun de la connexion pour des connexions inactives. Ou bien vérifier ce lien pour la connexion mise en commun ' http://www.mkyong.com/hibernate/how-to-configure-the-c3p0-connection-pool-in-hibernate/ '


0 commentaires

0
votes

En dehors de l'utilisation d'une seule version de JAR (que les autres utilisateurs ont suggéré), veuillez vérifier les éléments suivants:

  1. Assurez-vous que lorsque vous avez terminé la connexion de la base de données, ferme la connexion avec ferme () appel.
  2. Les erreurs comme ceci peuvent survenir lorsque vous ouvrez le nombre de connexions et ne les fermez pas explicitement.
  3. Dans ces situations, plusieurs fois, la base de données ferme réellement les connexions inactives, mais l'objet représentant cette connexion au côté de l'application n'est toujours pas fermé.
  4. Que se passe-t-il, ces objets de connexion ouverts sont cachés et lorsque le finaliseur fonctionne ( évident de la trace de pile ) et essaie de fermer la connexion, vous obtenez IllegalStateException Comme cet objet de connexion n'est associé à aucune connexion de base de données.

0 commentaires