Java.lang.IllegalStateException when rebooting Tomcat Server

I am working on Spring with a Hibernate application, the application works fine, but when I start or restart the tomcat server, I get a java.lang.IllegalStateException Exception.

Can someone explain why this exception occurs and how to solve it?

 INFO: Illegal access: this web application instance has been stopped already. Could not load java.net.BindException. 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:1600) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559) at com.mysql.jdbc.SQLError.createLinkFailureMessageBasedOnHeuristics(SQLError.java:1220) at com.mysql.jdbc.exceptions.jdbc4.CommunicationsException.<init>(CommunicationsException.java:57) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1074) at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3270) at com.mysql.jdbc.MysqlIO.quit(MysqlIO.java:1659) at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4296) at com.mysql.jdbc.ConnectionImpl.cleanup(ConnectionImpl.java:1265) at com.mysql.jdbc.ConnectionImpl.finalize(ConnectionImpl.java:2667) at java.lang.System$2.invokeFinalize(Unknown Source) at java.lang.ref.Finalizer.runFinalizer(Unknown Source) at java.lang.ref.Finalizer.access$100(Unknown Source) 
+6
source share
4 answers

I want to give you a couple of options. You can try. Any option can satisfy your requirement.

  • Restart your tomcat and apache server , because for a long time, it stores an older version of your application.
  • Empty the tomcat temp and restart directory
  • As indicated by mistake ,

A possible next stack trace is caused by an error caused by debugging, and also try to close the thread that caused illegal access and has no functional impact.

This may be the real reason that you are currently in debug mode and it does not clear the current thread. so remove the breakpoint and run it without debugging

  1. If your code contains any thread that has not been properly terminated, this type of error may occur. You have an init() method, but not a destroy() method, then this type of error may occur. For more information, you can follow the link - http://www.javaspecialists.eu/archive/Issue056.html

  2. if webapp has stopped, or is stopping , it means that the timestamp .war or WEB-INF/web.xml been changed and webapp can be reloaded. Please mark the time stamp is normal or not.

  3. To disable it, set reloadable = "false" in the context of your application definition. It could be tomcat server.xml . Detailed solution: The tomcat server.xml file of the reloadable context is set to false. For instance:

  Context path = "/ expert" docBase = "expert" debug = "0" reloadable = "false" />

The solution is easy if tomcat server.xml in reloadable = "true" into false on the line, but for this it will lose the advantage of hot deployment, and for development it is not very convenient, just change it or not. This error does not matter.

The principle of error:

The reason is that tomcat rebooted because the previous tomcat thread did not shut down completely, restart tomcat will report this exception, but this does not affect normal use, just jump over abnormal annoying people. Used by hibernate, spring or other large components when the WEB application system has many classes,

if you enabled Tomcat reloadable = true , then whenever the relevant documents change, Tomcat stops the web application and frees up memory, and then restarts the web application. it can be a huge project. Therefore, we always think that there is only a certain class of overloaded functions that largely correspond to our debugger.

UPDATE: for code issue

Firstly, I want to tell you that I have given you some solutions for the tomcat framework. Now I want to give you a solution for the code . Could you double-check your code with this problem? Follow the url.

  1. http://www.coderanch.com/t/660126/Wiki/Illegal-State-Exception

UPDATE: for MySQL related issue

  1. There are 2 problems.

    • This web application instance is already stopped. Failed to load java.net.BindException .

    • This instance of the web application has been stopped already. Failed to load com.mysql.jdbc .

This is due to the fact that the MySQL JDBC driver in the application in the WEB-INF/lib , when re-released it is loaded twice, if it can be copied to %TOMCAT_HOME%/lib , can solve the problem. We can solve these two MySQL driver anomalies from the WEB-INF/lib folder, migrated to %TOMCAT_HOME%/lib .

  1. 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.38 right now) in case something has been fixed that might affect you. (Number 9 copied from @ WhiteFang34)

Related link for 9: tomcat 6.0.24 Exception: Could not load com.mysql.jdbc.SQLError

+5
source

I think the main reason for this problem is that something is leaking JDBC Connection objects.

These objects are actually instances of com.mysql.jdbc.ConnectionImpl ... which is a class with finalize() . Typically, shutting down an object eliminates leakage of connections. In this case, the sequence of events is as follows:

  • GC starts after webapp shuts down
  • ConnectionImpl object is unavailable
  • The finalize () method of the object tries to disconnect the connection to the MySQL database ... which entails sending a message to the server
  • when for some reason a message is sent with an error, and the code at the coms level tries to throw an exception by calling com.mysql.jdbc.SQLError.createCommunicationsException
  • which tries to throw an exception reflectively ...

The last step does not work, because it is trying to use the webapp class loader for the web application ... that has been disabled. Apparently, this was discovered through a check, which is designed to help programmers diagnose webapps that do not close cleanly.

The best solution is to track the source of the Connection leak and fix it. If Connection objects have not leaked, then they will be closed while the Webapp class loader is still active.

Alternatively, you can simply turn off validation as described in @Skywalker's answer.

+2
source

The problem is with the server cache. Follow these steps to resolve this issue.

  • Find the directory called β€œwork” in the root directory of tomcat
  • Delete it completely
  • Reboot server

The problem will be fixed.

Note. If you have installed the default tomcat installation on a Linux machine, you need to delete the /var/cache/tomcat7/Catalina folder

+1
source

The problem may be a simple SQL error. Tthe

 java.lang.IllegalStateException 

means that the object or class was called when it was not ready for the call. These errors are at the bottom of the stack.

 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) 

It looks like they come from the Java Garbage Collector attempt to clear MySQL object pointers that were temporarily left out during the reboot. It seems to me that your mistake here is just a few pointers to MySQL objects that stop in the middle of execution when the GC calls their completion methods and then pauses the application to try to clear the object. (leading to the failure and throwing of this exception) This error is most likely harmless and can be fixed by adding

 JNI_DestroyJavaVM(); 

into your main thread, which will be executed upon completion of work.

+1
source

All Articles