Tomcat 6.0.44 "have failed to stop it. This was very likely to create a memory leak "issue survey

1. Cause of the problem

A cache module implementation in our project was Ehcache (2.4.3), and when the project was deployed to Tomcat, the Tomcat was stopped service operation, found that Tomcat could not stop properly, error appears to having started a thread named [XXX] but had failed to stop it. The very likely to create a memory Leak.java process does not end properly and requires a manual kill process.

Information: Stopping service Catalina2015-9-26 11:40:17Org.apache.catalina.loader.WebappClassLoader CLEARREFERENCESJDBC Serious: The Web application [/HD] registered the JDBC driver [Com.mysql.jdbc.Driver] but failed to unregister it when the Web application was Stoppe D. To prevent a memory leak, the JDBC Driver have been forcibly unregistered.2015-9-26 11:40:17Org.apache.catalina.loader.WebappClassLoader clearreferencesthreads Serious: The Web application [/HD] appears to has started a thread named [pool-2-thread-1] but had failed to stop it. This was very likely to create a memory leak.2015-9-26 11:40:17Org.apache.catalina.loader.WebappClassLoader clearreferencesthreads Serious: The Web application [/HD] appears to had started a thread named [[email protected]] but had failed to stop it. This was very likely to create a memory leak.2015-9-26 11:40:17Org.apache.catalina.loader.WebappClassLoader clearreferencesthreads Serious: The Web application [/HD] appears to had started a thread named [Org.hibernate.cache.spi.UpdateTimestampsCache.data] but had failed to stop It. This was very likely to create a memory leak.2015-9-26 11:40:17Org.apache.catalina.loader.WebappClassLoader clearreferencesthreads Serious: The Web application [/HD] appears to had started a thread named [Org.hibernate.cache.internal.StandardQueryCache.data] but had failed to St OP it. This was very likely to create a memory leak.2015-9-26 11:40:17Org.apache.coyote.http11.Http11Protocol Destroy info: Stopping Coyote HTTP/1.1 on http-8080

2. Ehcache thread does not automatically stop the problem

After analysis, it is found that three threads that are Ehcache cannot automatically stop (or Ehcache not end when the app stops/JVM stopped).

After analysis, it is found that the listener can be added to the Web application and trigger the ehcache of releasing resources and threads when the destory is applied.

3. Must you add listener?

After parsing the Ehcache code, it was found that using the system parameters-dnet.sf.ehcache.enableshutdownhook=true enabled the Ehcache JVM shutdown hook.

Net.sf.ehcache.CacheManager

/*** Some caches might be persistent, so we want to add a shutdown hooks if that's the * case, so that the data     And index can is written to disk. */    Private voidaddshutdownhookifrequired () {String Shutdownhookproperty=System.getproperty (Enable_shutdown_hook_property); BooleanEnabled =Propertyutil.parseboolean (Shutdownhookproperty); if(!enabled) {            return; } Else{log.info ("The CacheManager shutdown hook is enabled because {} are set to True.", Enable_shutdown_hook_property); Thread Localshutdownhook=NewThread () {@Override Public voidrun () {synchronized( This) {                        if(Status.equals (status.status_alive)) {//Clear shutdown hook reference to prevent//Removeshutdownhook to remove it during shutdownShutdownhook =NULL; Log.info ("VM shutting down with the CacheManager still active. Calling shutdown. ");                        Shutdown ();            }                    }                }            };            Runtime.getruntime (). Addshutdownhook (Localshutdownhook); Shutdownhook=Localshutdownhook; }    }

JVM Shutdown Hook Note:

Tomcat's own Shutdown.sh/bat cannot send an exit signal to the Java process, and the JVM shutdown hook cannot be triggered.

A kill $pid is required for the JVM shutdown hook to be triggered

4. The previous project used the Hibernate3, two-level cache relies on Ehcache, why not the problem

Where did you add the destory?

Prepare the demo, verify that the same problem exists. Just because Hibernate3 (3.2.5GA) relies on the lower version of Ehcache (1.2.3), the threads that are not stopped are hibernate and some other parts.

The logs are as follows:

2015-9-26 10:53:15 org.apache.catalina.core.StandardService Stop info: Stopping service catalina2015-9-26 10:53:15 Org.apache.catalina.loader.WebappClassLoader CLEARREFERENCESJDBC Critical: The Web application [/HD] registered the JDBC driver [Com.mysql.jdbc.Driver] but failed-unregister it when the Web application was stopped. To prevent a memory leak, the JDBC Driver have been forcibly unregistered.2015-9-26 10:53:15 Org.apache.catalina.loader.Web Appclassloader clearreferencesthreads Critical: The Web application [/HD] appears to has started a thread named [Store org.hiber Nate.cache.UpdateTimestampsCache Spool Thread] but had failed to stop it. This was very likely to create a memory leak.2015-9-26 10:53:15 org.apache.catalina.loader.WebappClassLoader Clearreferenc Esthreads Critical: The Web application [/HD] appears to has started a thread named [Store Org.hibernate.cache.UpdateTimestampsC Ache expiry Thread] but had failed to stop it. This was very likely to create a memory leak.2015-9-26 10:53:15 Org.apAche.catalina.loader.WebappClassLoader clearreferencesthreads Critical: The Web application [/HD] appears to has started a thre Ad named [Store Org.hibernate.cache.StandardQueryCache Spool Thread] but had failed to stop it. This was very likely to create a memory leak.2015-9-26 10:53:15 org.apache.catalina.loader.WebappClassLoader Clearreferenc Esthreads Critical: The Web application [/HD] appears to has started a thread named [Store Org.hibernate.cache.StandardQueryCach E expiry Thread] but had failed to stop it.  This is very likely to create a memory leak.2015-9-26 10:53:15 org.apache.coyote.http11.Http11Protocol destroy info: Stopping Coyote http/1.1 on http-80802015-9-26 10:53:15 org.apache.catalina.loader.WebappClassLoader loadclass

The previous projects are on the line, why not this problem?

Is it a tomcat version? Switch the tomcat version from 6.0.44 to 6.0.37 to find that the problem is no longer reproducible. That is to say, 6.0.37 Tomcat did not do such a check when shutdown.

Tomcat 6.0.44 "have failed to stop it. This was very likely to create a memory leak "issue survey