Tomcat JDBC Pool – Connection Leak – Catch the Culprit

Database connection leaks are something that can stay hidden unless paid specific attention and would come to the surface at the most critical stages at a peak time of the system. We would manually check if all the open connections have been closed properly. Then we have various code quality plugins that would scan and check for that. Still when the connections are passed through a complex structure of program both of these can miss a possible connection leak. Then at unit test or integration test levels, we can have checks to validate the counts in the connection pool to avoid this unfortunate situation, that would keep engineers busy at year-end, black Friday, etc. :)

In the unfortunate case of hitting with a performance degrade or a total crash of the system which can be propagated via a JDBC connection leak, when we suspect a connection leak, how easily and quickly isolate the culprit. In the Tomcat connection pool, we can do this using 3 properties.

removeAbandoned

If a DB connection has been abandoned(not been used for a while, but haven’t returned to the pool), this configuration will try to remove it. How long to wait before it removes the connection is configured by the below configuration.

removeAbandonedTimeout

The time it will spare before attempting to remove the connection. By default 60s.

Note: When we are using this property with a target to isolate a culprit, it is useful to know the average time taken by the longest transaction the system would execute on the database. Setting this value considerably larger than that would avoid us from catching the innocent threads that might be actually doing useful work would get properly closed at the end.

logAbandoned 

‘Should it log the stack trace when removing an abandoned connection’ is governed by this. 

More details on these properties can be found at
https://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html#Common_Attributes

These configurations can also be used as a safety net in case you are doubtful if the application has any leak. Because it will automatically remove the connections that have been forgotten to be closed and the pool will handle to keep the intended min, max and idle connection count properly considering those.

This is a sample log I got captured while the pool removes an abandoned connection.

As you can the whole stack trace relevant to the abandoned connection creation is captured here, which will lead us to the culprit faster.

Optionally, we also have the option of using JConsole to monitor the JDBC pool via JMX. For that, we need to enable the property‘jmxEnabled' which will allow connecting from Jconsole to the JDBC pool. Once done it has a whole lot of features to monitor the pool and can even set to notify when a connection is detected to be abandoned.

Hope this will help you save some time in troubleshooting.

Cheers!

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

I agree to the Terms and Privacy Policy

Sign up

Thank you!

We will contact you soon.