java.lang.IllegalStateException while reloading Tomcat

I want to give you couple of choices. You can try it. Any option can fulfill your demand.

1. Restart your tomcat and apache server because a long time of using, it keeps older version of your application.
2. Clean your tomcat temp directory and restart
3. As stated in error,

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.

It may be the real cause that at this moment you are in debugging mode and it doesn't clear the running thread. so remove your break point and run it not debugging

4. If your code contains any kind of thread which are not properly terminated, then this type of error may occur. That you have init() method but no destroy() method, then this type of error may occur. For details, you can follow the link - http://www.javaspecialists.eu/archive/Issue056.html

5. if the webapp has stopped, or is stopping, that means that the .war file or WEB-INF/web.xml timestamp changed, and the webapp might be reloading. Please check timestamp is OK or not.

6. To turn it off, set reloadable="false" in the context definition of your app. It might be tomcat's server.xml. In details solution: The tomcat's server.xml of the reloadable Context is set to false. For example:

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

The solution is easy, as long as the tomcat's server.xml in reloadable = "true" into false on the line, but to do so would lose the advantage of hot deployment, and for the development is not very convenient, simply change it or not. This error does not matter.

Error principle:

The reason is because the tomcat restart, because the previous tomcat thread has not completely shut down, restart tomcat will report this exception, but this does not affect the normal use, just jump abnormal annoying people. Used hibernate, spring or other large components, when a WEB application system has a lot of class,

if you turned the Tomcat reloadable = true, then whenever the relevant documents change, Tomcat stops web app and frees up memory, and then reload web app. it may be a huge project. So we always think if there is only a certain class of overloaded functions, will greatly meet our debugger.

UPDATE: For code related issue

First, I want to tell you that I have given you some solutions for tomcat basis. Now I want to give you a solution for code basis. Would you please cross check your code with this issue? Please follow the URL.

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

UPDATE: For MySQL related issue

8. There are 2 issues.

   • This web application instance has been stopped already. Could not load java.net.BindException.

   • This web application instance has been stopped already.Could not load com.mysql.jdbc.

This is because the MySQL JDBC driver on the application under the WEB-INF/lib directory, in the re-release of its loaded twice, so long as it can be copied to %TOMCAT_HOME%/lib can solve the problem. We can solve these two anomalies MySQL drivers from the WEB-INF/lib folder moved to %TOMCAT_HOME%/lib.

9. I suspect this might be happening after the web application is restarted, where it's down for a short period of time. Then some finalize() method in the code is probably trying to do some cleanup too late. Whether or not that's in your code or the MySQL driver I can't say. You definitely should only have one version of a jar in a directory at a time. You might want to upgrade it to the latest (5.1.38 right now) in case something has been fixed that might be affecting you.(Number 9 is copied from @WhiteFang34)

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

I think that the root cause of 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 a finalize(). Normally, object finalization tidies up the leaked connections. In this case, it looks like the sequence of events is as follows:

• the GC runs after the webapp has shutdown
• a ConnectionImpl object is found to be unreachable
• the object's finalize() method attempts to shutdown the MySQL database connection ... which entails sending a message to the server
• when the message send fails for some reason, and the comms-level code tries to create an exception by calling com.mysql.jdbc.SQLError.createCommunicationsException
• that tries to create an exception reflectively ...

The last step is failing because it is trying to use the webapp's classloader for the webapp ... which has been shut down. Apparently, this is detected by a check that is intended to help programmers diagnose webapps that don't shutdown cleanly.

The best solution is to track down the source of the Connection leak(s) and fix it. If Connection objects did not leak, then they would be closed while the webapp's classloader was still active.

Alternatively, you could simply turn off the check, as described in @Skywalker's answer.