Tomcat 6.0.24 Exception: Failed to load com.mysql.jdbc.SQLError

Question

My tomcat 5 server running on centos often (several times / day) causes the following error:

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) 

The tomcat lib directory contains mysql-connector-java-5.1.8-bin.jar and mysql-connector-java-5.1.6-bin.jar, while the WEB-INF / lib directory contains only mysql-connector-java -5.1. 8-bin.jar. All three jar files contain the SQLError class.

I would like to exclude this exception. Could tomcat look elsewhere to try and find this class?

Answer 1

The error is not that the class cannot be found. It is not allowed to download because the web application has been stopped. I suspect this may happen after restarting the web application, where it will run for a short period of time. Then some finalize() method in the code is probably trying to do some cleanup too late. No matter what I can say in the code or in the MySQL driver. You should definitely have only one version of the jar in the catalog at a time. You might want to update it to last (5.1.15 right now) in case something has been fixed, which may affect you.

Answer 2

Use only one version of the jar file in the WEB-INF / lib directory. It is better to use the latest version of mysql-connector-java 5.1.26.

Answer 3

Newer versions of Tomcat require that you place JDBC JAR files in the Tomcat / lib directory, and not in your WEB-INF. And in this directory there should be only one version - the version you want to use, and others.

Since you are using Tomcat 5, I would recommend placing the JAR in your server / lib directory.

I do not know if this is the main cause of your problem, but it is worth a try.

Answer 4

You can check the order of directories in the classpath. I once had two versions of the jar file: one in the working directory and the other in the Java Extensions directory. The order of the class path: first check the eclipse extension directory, then the second working directory. As soon as he found the jar version in the extensions directory, he did not continue to search for the one I specified in the working directory. Order matters in the class path.

Answer 5

Where is the JDBC connection pool configured? Is it in Tomcat JNDI (conf / server.xml) or directly in your application? Is one of your web applications not deployed / redistributed when this message appears?

From stacktrace and the source code of MysqlIO.java and WebappClassLoader.java I would suggest that:

• one of the webapps is not deployed - based on the code in WebappClassLoader:

  // Log access to the stopped class loader

  if (! started) {try {throw new IllegalStateException (); } catch (IllegalStateException e) {log.info (sm.getString ("webappClassLoader.stopped", name), e); }}

• your JDBC connections are not cleared correctly during shutdown of the web application (your ServletContextListener.contextDestroyed should execute this or, for example, Spring bean parameter of the destroy-method method)

• some of the classes that are used by the MySQL driver code are unloaded by GC
• these connections are GC acceptable when your application terminates, but GC detects that the MySQL connection termination method is overridden, so it executes it
• When this finalize method is executed, it needs a class that needs to be loaded. The Tomcat class loader of your stopped web application detects it and reports that there should not be other classes loaded by the stopped web application.

My solution to your problem was to check how the JDBC connection pool is cleared when the web application shuts down, and make sure the pool is also explicitly disconnected.

Answer 6

Most likely, you are connecting the connection pool in your application, which checks the connection to the database.

Answer 7

I think you need to use the join join mechanism for idle connections. or check this link for pooling http://www.mkyong.com/hibernate/how-to-configure-the-c3p0-connection-pool-in-hibernate/ '

Answer 8

Besides using only one version of jar (which other users have suggested), please also check the following:

• Make sure that after the connection to the database is completed, close the connection when calling close() .
• Errors like this can occur when you open the number of connections and do not explicitly close them.
• In these situations, many times the database actually closes idle connections, but the object representing this connection on the application side is still not closed.
• What happens is that these open connection objects are hidden, and when the finalizer works (obviously from the stack trace) and tries to close the connection, you get an IllegalStateException , because this connection object is not connected to any database connection.