c3p0 Pooled Connections Phantom connections

Question

I run an application on Tomcat7 with c3p0 as the datasource pooling manager. I added a connection customizer to log each datasource Acquired/check out/in.

My log (catalina.out) contains a number of entries thus:

Acquired com.cloudera.impala.jdbc41.ImpalaJDBC41Connection@e5059be [z8kfsx9f16wfz9m1p2ghf4|729e8277] Acquired com.cloudera.impala.jdbc41.ImpalaJDBC41Connection@217a2a9 [z8kfsx9f16wfz9m1p2ghf4|729e8277] Checking in com.cloudera.impala.jdbc41.ImpalaJDBC41Connection@e5059be Checked out com.cloudera.impala.jdbc41.ImpalaJDBC41Connection@e5059be

I also noticed a number of sql exceptions like:

java.sql.SQLException: Some resources failed to close properly while closing com.mchange.v2.c3p0.impl.NewPooledConnection@6c5ca37c at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:571) at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:234) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.destroyResource(C3P0PooledConnectionPool.java:470) at com.mchange.v2.resourcepool.BasicResourcePool$1DestroyResourceTask.run(BasicResourcePool.java:964) at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)

When I search the log file for “6c5ca37c”, I don’t see any line(s) that indicates when the connection was ever acquired. Parsing the log shows me that ALL connections that were “Acquired” where “Destroyed” successfully but all the connections that show up with the sql exception do not have any corresponding Acquired line

Any insight will be helpful.

Answer 1

Sorry for the slow response. I've been off the grid lately.

A com.mchange.v2.c3p0.impl.NewPooledConnection is a distinct object from a com.cloudera.impala.jdbc41.ImpalaJDBC41Connection. The first wraps and instance of the second, but they won't have consistent identity hash code values (which become the hex part of the default toString() method).

In and of itself the Exception that you are seeing isn't too concerning. c3p0 is very neurotic about closing things, and if it is not sure that, say, a ResultSet or Statement has been close()ed, it will try to close() them. If they have already bee invalidated somehow, they may throw Exceptions on close(), leading to this message.

I would check elsewhere in logs (before this stack trace), to see if something else has gone wrong prior to the Exceptions on close that might be more concerning. If there is a prior problem, that may be more informative. If you can, I'd make sure that the application is careful to close() ResultSets and Statements. Otherwise, if the application is performing OK, I wouldn't worry very much about these occasional messages. c3p0 will have made a call to close() to your Connection, after it has tried to close each resource that may remain open for that Connection. Exceptions on attempted close() of subsidiary resources does not prevent c3p0 from making a best-attempt close() of the Connection, so unless something is badly broken on the JDBC-side (conn.close() fails), there will be no resource leak.