Memory leaks in Tomcat 7.0.50

Question

We are currently using Apache Tomcat 7.0.50 deployed with multiple web application instances and where we are trying to fix some of the Bugs in the catalina.out which appears severe. Two of those are as below.

• org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SEVERE: The web application [/app_name] created a ThreadLocal with key of type [class name] (value [class name]) and a value of type [classname] (value [classname@4b188d84]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

• org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc SEVERE: The web application [/app_name] registered the JDBC driver [oracle.jdbc.driver.OracleDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.

We have really seen many solutions to these errors above in various communities, blogs and FAQ sessions, but are trying to find

1. Why are these happening to be precise?

2. Are these considered severe and needs to be fixed , for sure?

3. How can we resolve , or work around these with some Apache Tomcat configurations? We have tried many in context.xml, web.xml, server.xml etc, but couldn't succeed.

4. In the worst case, if at any case these can be hidden from catalina.out, how can we do that?

Kindly help us here. Any help would be appreciated and accepted. Thanks in advance.

Note: For iten 2, I have found a solution as mentioned in Oracle driver memory leak - Tomcat but have not given it a try. Will that really work for Tomcat 7.0.50?

Regards, Sam Mohan.

Answer 1

Both of these warnings happen for much the same reason. An object outside of the web application is holding onto a reference to an object that is within the application. These are code level problems that cannot be fixed via configuration.

How big a problem this turns out to be in practice really depends on 1) how often you hot undeploy/redeploy the application in question and 2) how big parts of the application that are being held on to are. I typically find that this problem stings me a lot more in development where I hot swap apps a lot, but much less so in production because I tend to restart tomcat as a deploy updates. Redeploy an app with this problem enough times, and the JVM will crash from running out of memory.

This particular problem cannot be resolved from a configuration change, unless you count scripting a server restart as a configuration solution. You will need to make code changes to break the object references that point into the web app. They can be fairly tricky to track down, but as the warnings highlight start by reviewing the use of all thread locals. A more complete review would include taking a heap dump of tomcat after unloading the application and then using a heap analyser to trace in memory references to the application that was unloaded (there should be none!).