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)
8 Réponses :
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 () code> 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. p>
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. P>
Puisque vous utilisez Tomcat 5, je vous recommande de mettre le pot dans votre répertoire serveur / lib. P>
Je ne sais pas si c'est la cause première de votre problème, mais ça vaut la peine d'essayer. P>
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. P>
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? P>
du code StackTrace et source de mysqlio.java et webappClassloader.java je devinerais que: p>
L'une des webapps est autorisé - basé sur le code dans WebAppClassloader: P>
// Log Accès au chargeur de classes arrêté p>
si (! a commencé) { essayer { jeter de nouvelles exceptions illégales (); } Catch (illegalStateException E) { log.info (sm.getstring ("webappClassLoader.sopped", nom), e); } } p> li>
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) p> li>
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é. P>
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. P>
Utilisez une seule version du fichier JAR dans Web-Inf / Lib code>. Mieux vaut utiliser la dernière version de
mysql-connecteur-java 5.1.26 code> strong>. P>
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/ ' P>
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: P>
ferme () code> appel. li>
- Les erreurs comme ceci peuvent survenir lorsque vous ouvrez le nombre de connexions et ne les fermez pas explicitement. li>
- 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é. li>
- Que se passe-t-il, ces objets de connexion ouverts sont cachés et lorsque le finaliseur fonctionne ( évident de la trace de pile em>) et essaie de fermer la connexion, vous obtenez
IllegalStateException code> Comme cet objet de connexion n'est associé à aucune connexion de base de données. li>
ol>
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.