Tomcat appears to prevent a memory leak, the JDBC Driver have been forcibly unregistered. A case record of the problem

• The issue occurs in the background:

Recently refactored an old project, the project has been involved in maintenance of more people, the code is very messy, so it was a small refactoring and upgrade, the system environment from Jdk1.6+tomcat6+windowsserver upgrade Jdk1.8+tomcat8+linux, But there was an error when refactoring was complete, and Tomcat was unable to start.

• Error message

To prevent a memory leak, the JDBC Driver have been forcibly unregistered. This error:

• Information for reference

Refer to the question above stack overflow:

Http://stackoverflow.com/questions/3320400/to-prevent-a-memory-leak-the-jdbc-driver-has-been-forcibly-unregistered

Http://stackoverflow.com/questions/2604630/tomcat-fails-to-start-because-of-jdbc-driver-loading

Starting with version 6.0.24, Tomcat added the memory leak detection feature, since the original Tomcat version was 6.0.24 versions Earlier, there was no similar problem, but after upgrading to TOMCAT8, there was a long list of repeated error messages, warning To prevent a memory leak, the JDBC Driver have been forcibly unregistered.

BALUSC's advice:

2. Ignore those warnings. Tomcat is doing it job right. The actual bug is in someone else's code (the JDBC driver in question) and not in yours. Be happy this Tomcat did it job properly and wait until the JDBC driver vendor get it fixed so that can upgrade the D River. On the other hand, you aren ' t supposed to drop a JDBC driver in WebApp's? /WEB-INF/lib , but only in server ' s? /lib . If you still keep it in WebApp's?, then you /WEB-INF/lib should manually register and deregister it using a? ServletContextListener .

4. Downgrade to Tomcat 6.0.23, or older so, you'll is not being bothered with those warnings. But it'll silently keep leaking memory. Not sure if that's good to know after all. Those kind of memory leaks is one of the major causes behind? OutOfMemoryError ? Issues?during Tomcat hotdeployments.

6. Move the JDBC driver to Tomcat ' s? /lib ? folder and has a connection pooled datasource to manage the driver. Note that Tomcat's builtin DBCP does not deregister drivers properly on close. See also bug? Dbcp-322?which is closed as Wontfix. You would rather "like" to "replace DBCP by another" connection pool which is doing it job better then DBCP. For example? HIKARICP, huh? BONECP, or perhaps? Tomcat JDBC Pool.

The driver and connection pools for JDBC are adjusted according to the third article in BALUSC's recommendation, but the problem persists.

To prevent a memory leak, the JDBC Driver have been forcibly this error is very confusing because the log output error message does not provide enough valuable information to solve the problem.

Sometimes, especially when using Spring application on Tomcat, the error message was Misleading-when there is no relation To any of the JDBC driver error at all and only a failure of some application BEAN Init-method (or @PostConstruct). The error stack trace is hidden and appears only in Tomcat/logs/localhost.xxx file. Just is aware of this behavior. It costed me a lot of time.

• Conclusions and Solutions

Conclusion:when running spring project in Tomcat, the error of console output is very confusing, sometimes it just occurs when some beans are initialized or @postconstruct, but the console output JDBC driver error , these error messages do not help to resolve the problem, and the real error message exists in the Tomcat/logs/localhost.xxx file.

At this point, the solution to the problem is very clear, only need to go to the Tomcat/logs/localhost.xxx file to find the real error message, according to the real error information to solve the problem in the code, the problem naturally followed by the solution.

Tomcat appears to prevent a memory leak, the JDBC Driver have been forcibly unregistered. A case record of the problem