tomcat启动过程报the JDBC Driver has been forcibly unregistered问题的修复过程

  最近两天在整理关于flume的总结文档，没有启动过tomcat。昨天晚上部署启动，发现报了如题的错误，全文如下：

严重: 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 has been forcibly unregistered.
2016-3-10 9:49:08 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
严重: The web application [/oa-deploy] registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
2016-3-10 9:49:08 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
严重: The web application [/oa-deploy] appears to have started a thread named [Timer-1] but has failed to stop it. This is very likely to create a memory leak.
2016-3-10 9:49:08 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
严重: The web application [/oa-deploy] appears to have started a thread named [Resource Destroyer in BasicResourcePool.close()] but has failed to stop it. This is very likely to create a memory leak.

   首先我怀疑可能与启动过程中的其他报错有关，在启动过程中频繁地报出了这样的错误：

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)

   目测这段错误信息，包含了tomcat，也包括了我们自有的代码信息，这让我以为tomcat无法启动可能与该错误有关。我通读了代码，并将该代码与服务器和其他同事的代码对比，发现一致，理论上不是这里的问题。

   开始百度，以下是百度到的错误解决方案：

1. registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web applica问; 

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. 异常 A web application registered the JBDC driver; 

5. he web application [] registered the JDBC driver [com.mysql.jdbc.Driver] but;  

6. 
   

   tomcat关闭应用时的清理工作(1): JDBC Driver的检测和反注册

特别是5、6两篇文章思考的比较深入，介绍的也比较详细，给出了自己的解决方案，2则是apache官方的关于该问题的讨论方案，部分工程师认为这是tomcat的一个bug。

   我并不认为是bug，我认为是代码导致的问题，我向所有工程师发出求助邮件，其中一位高级工程师回复“检查C6 数据源是否畅通”，C6数据源是jdbc.properties里配置的三个数据源之一。昨天我确实因为使用无线网导致C6连接不上反映过该问题。我修改了C6数据源配置并且切换到有线内网，错误仍然存在。

   第六篇文章给了我较多启发，作者hongjiang应该是tomcat的一位资深研究人员，发表了多篇关于tomcat的研究文章，其对该错误的分析摘要如下：

        tomcat在关闭应用时，对资源做了一些清理，避免了泄露，这个工作主要是WebappClassLoader里做的，WebappClassLoader也实现自Lifecycle接口，在应用关闭时，会触发其stop方法，其中对JDBC Driver的清理，是clearReferencesJdbc方法，它检查当前WebappClassLoader加载过的，在关闭时未注销掉的JDBC Driver，给出警告信息，并强行将这些Driver反注册掉。如果servlet在初始化时注册了一个Driver，但销毁时未将这个Driver给反注册掉；这时不管是显式的通过命令来stop tomcat，还是因为设置了自动reload，而且恰好检查到应用有变，执行了reload的时候(reload也是对app context进行stop，然后再重新start)，就会被tomcat判断为泄露，给出警告并强制反注册Driver。

    要避免这个信息，应用或框架应该自己来保证在销毁时将JDBC Driver反注册掉。例如在destroy方法里：

@Override
	public void destroy() {
	    super.destroy();
	    try{
	        DriverManager.deregisterDriver(DriverManager.getDrivers().nextElement());
	    }catch(Exception e){
	        e.printStackTrace();
	    }
	}

   因为tomcat自带了DBCP数据库连接池，很多用户在使用DBCP时遇到了这个问题，并建议在 DBCP 的 BasicDataSource的close方法里执行反注册驱动的行为来解决这个警告。但DBCP的开发者认为这个应该是使用者的责任，不愿意接受这种建议。

         关闭reloadable重启该问题未再重现。