Tomcat boot process reported the JDBC Driver has been forcibly unregistered problem repair process

In the last two days, I have compiled a summary document about Flume and did not launch Tomcat. The deployment started last night, found the title error, the full text is as follows:

Critical: The Web application [/oa-deploy] registered the JBDC driver [Com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed To unregister it when the Web application was stopped. To prevent a memory leak, the JDBC Driver have been forcibly unregistered.
2016-3-10 9:49:08 Org.apache.catalina.loader.WebappClassLoader Clearreferencesjdbc
Critical: The Web application [/oa-deploy] registered the JBDC driver [Com.mysql.jdbc.Driver] but failed-unregister it when t He web application was stopped. To prevent a memory leak, the JDBC Driver have been forcibly unregistered.
2016-3-10 9:49:08 Org.apache.catalina.loader.WebappClassLoader clearreferencesthreads
Critical: The Web application [/oa-deploy] appears to had started a thread named [Timer-1] but had failed to stop it. This was very likely to create a memory leak.
2016-3-10 9:49:08 Org.apache.catalina.loader.WebappClassLoader clearreferencesthreads
Critical: The Web application [/oa-deploy] appears to has started a thread named [Resource Destroyer in Basicresourcepool.close ()] but had failed to stop it. This was very likely to create a memory leak.

First of all I suspect that it may be related to other errors during the startup process and frequently reported such errors during startup:

2016-03-10 11:21:01,117 [main] DEBUG [com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug] The result Type [Com.fx.platform.web.struts.result.JsonResult] doesn ' t have a default param [Default_param] defined!

Java.lang.NoSuchFieldException:DEFAULT_PARAM

At Java.lang.Class.getField (class.java:1520)

At Com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.addResultTypes ( xmlconfigurationprovider.java:578)

At Com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.addPackage (Xmlconfigurationprovider.java : 530)

At Com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadPackages (Xmlconfigurationprovider.java : 292)

At Org.apache.struts2.config.StrutsXmlConfigurationProvider.loadPackages (Strutsxmlconfigurationprovider.java : 112)

At Com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer (defaultconfiguration.java:250)

At Com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration (configurationmanager.java:67)

At Org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration (dispatcher.java:446)

At Org.apache.struts2.dispatcher.Dispatcher.init (dispatcher.java:490)

At Org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher (initoperations.java:74)

At Org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init ( STRUTSPREPAREANDEXECUTEFILTER.JAVA:57)

At Org.apache.catalina.core.ApplicationFilterConfig.getFilter (applicationfilterconfig.java:295)

At Org.apache.catalina.core.ApplicationFilterConfig.setFilterDef (applicationfilterconfig.java:422)

At Org.apache.catalina.core.applicationfilterconfig.<init> (applicationfilterconfig.java:115)

At Org.apache.catalina.core.StandardContext.filterStart (standardcontext.java:4001)

At Org.apache.catalina.core.StandardContext.start (standardcontext.java:4651)

At Org.apache.catalina.core.ContainerBase.start (containerbase.java:1045)

At Org.apache.catalina.core.StandardHost.start (standardhost.java:785)

At Org.apache.catalina.core.ContainerBase.start (containerbase.java:1045)

At Org.apache.catalina.core.StandardEngine.start (standardengine.java:445)

At Org.apache.catalina.startup.Embedded.start (embedded.java:825)

At Org.codehaus.mojo.tomcat.AbstractRunMojo.startContainer (abstractrunmojo.java:558)

At Org.codehaus.mojo.tomcat.AbstractRunMojo.execute (abstractrunmojo.java:255)

At Org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (defaultbuildpluginmanager.java:101)

At Org.apache.maven.lifecycle.internal.MojoExecutor.execute (mojoexecutor.java:209)

At Org.apache.maven.lifecycle.internal.MojoExecutor.execute (mojoexecutor.java:153)

At Org.apache.maven.lifecycle.internal.MojoExecutor.execute (mojoexecutor.java:145)

At Org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (lifecyclemodulebuilder.java:84)

At Org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (lifecyclemodulebuilder.java:59)

At Org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild (lifecyclestarter.java:183)

At Org.apache.maven.lifecycle.internal.LifecycleStarter.execute (lifecyclestarter.java:161)

At Org.apache.maven.DefaultMaven.doExecute (defaultmaven.java:320)

At Org.apache.maven.DefaultMaven.execute (defaultmaven.java:156)

At Org.apache.maven.cli.MavenCli.execute (mavencli.java:537)

At Org.apache.maven.cli.MavenCli.doMain (mavencli.java:196)

At Org.apache.maven.cli.MavenCli.main (mavencli.java:141)

At Sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)

At Sun.reflect.NativeMethodAccessorImpl.invoke (nativemethodaccessorimpl.java:39)

At Sun.reflect.DelegatingMethodAccessorImpl.invoke (delegatingmethodaccessorimpl.java:25)

At Java.lang.reflect.Method.invoke (method.java:597)

At org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (launcher.java:290)

At Org.codehaus.plexus.classworlds.launcher.Launcher.launch (launcher.java:230)

At Org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (launcher.java:409)

At Org.codehaus.plexus.classworlds.launcher.Launcher.main (launcher.java:352)

The visual of this error message, including Tomcat, and our own code information, makes me think that Tomcat could not be started with this error. I read through the code and compared the code with the server and other colleagues ' code, and found the consistency, which is not theoretically the problem.

Start Baidu, the following is Baidu to the wrong solution:

1. Registered the JDBC driver [Com.mysql.jdbc.Driver] but failed to unregister it when the web Applica asked;

2. Closing Basicdatasource doesn ' t deregister JDBC driver, causing memory leak;
3. The Web application [] registered the JDBC driver [Com.mysql.jdbc.Driver] but failed to unregister I
4. Exception A Web application registered the JBDC driver;
5. He Web application [] registered the JDBC driver [com.mysql.jdbc.Driver] but;
6. 
   Clean up when Tomcat shuts down the app (1): Detection and anti-registration of JDBC driver

In particular, 5, 62 articles thinking of a more in-depth, the introduction of the more detailed, give their own solution, 2 is the official Apache of the discussion on the issue of the program, some engineers think this is a bug of Tomcat.

I do not think it is a bug, I think it is the code caused by the problem, I sent to all the engineers to help mail, one of the senior engineer replied " Check C6 data source is unblocked ", C6 data source is one of the three data sources configured in Jdbc.properties. Yesterday I did because the use of wireless network caused C6 connection does not reflect the problem. I modified the C6 data source configuration and switched to the wired intranet, and the error persists.

The sixth article gives me more inspiration, the author Hongjiang should be a veteran of Tomcat, published a number of research articles on Tomcat, the analysis of this error is summarized as follows:

when Tomcat shuts down the application, it cleans up the resources and avoids the leaks, which is mainly done in WebappClassLoader, WebappClassLoader also implements the lifecycle interface, when the application shuts down, Triggers its Stop method, where cleanup of the JDBC Driver is the Clearreferencesjdbc method, which checks the current WebappClassLoader-loaded JDBC Driver that did not log off at shutdown, giving a warning message, And forcibly put these driver back into the register. If the servlet registers a driver at initialization, but the driver is not reversed when it is destroyed, either explicitly by using the command to stop Tomcat, or because the automatic reload is set, and happens to check that the application has changed, the reload is executed. (Reload is also a stop to app context and then start again), it will be judged by Tomcat as a leak, give a warning and force anti-registration driver.

To avoid this information, the application or framework should ensure that JDBC driver are unregistered at the time of destruction. For example in the Destroy method:

@Overridepublic void Destroy () {Super.destroy ();    try{Drivermanager.deregisterdriver (Drivermanager.getdrivers (). Nextelement ());    }catch (Exception e) {e.printstacktrace (); }}

because Tomcat comes with a DBCP database connection pool, many users encounter this problem when using DBCP and recommend that the DBCPBasicDataSourceof theclosemethod to implement the anti-registration driver behavior to resolve this warning. But DBCP's developers think this should be the user's responsibility and unwilling to accept such advice.

Turn off reloadable Restart the issue is not reproduced again.

This article is from the "Jiangnan Miner Technology Space" blog, please be sure to keep this source http://jncumter.blog.51cto.com/812546/1749568

Tomcat boot process reported the JDBC Driver has been forcibly unregistered problem repair process