commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [DBCP] Apparent deadlock related to getConnection
Date Sun, 12 Apr 2015 15:16:26 GMT
On 4/12/15 2:58 AM, Shawn Heisey wrote:
> On 4/11/2015 8:48 AM, Phil Steitz wrote:
>> What is going on in that thread is that it is blocked waiting for a
>> connection to become available in the pool.  There is no evidence of
>> deadlock there - just pool exhaustion.
>> The most likely culprit is application code that is failing to close
>> connections that have been borrowed from the pool.  If you don't
>> close the connections on all execution paths, they will "leak" as
>> the pool has no way of knowing that your code is finished with them
>> unless and until you close them.
> I've done a review of all my database code for leaks in the past, and
> everything looked good at that time.  I can repeat that check.  The
> database portions of my code have not had any changes for quite some time.

Also try turning on removeAbandoned and logAbandoned.
> Would I see evidence of a connection leak in the "show full processlist"
> output at the MySQL server?  I don't see that happening.  There are only
> a handful of open connections when I check there, even when the program
> has been running for several days or weeks, running through its cycle
> once a minute.  Once all parts of the program have been run at least
> once, the connection count is stable.

Can you post your full pool config and info on versions of DBCP and

Do you call isClosed() before closing a connection (not recommended
- that is really the issue in the ticket you commented)?

To make sure there is not an actual deadlock somewhere, you should
examine a full thread dump.  The thread you posted in the ticket is
waiting on the pool, not holding any DBCP or POOL related locks; but
it does hold this application lock:
at com.REDACTED.idxbuild.solr.Chain.doReinsert(
        - locked <0x00000000db0011c8> (a java.lang.Object)
Make sure no other threads in process of doing things that will
return connections to the pool aren't waiting on this lock.

Given that you are using DBCP 2.1, if you have access to a JMX
console it would also be good to look at what is happening in the
pool when your application hangs.  In particular, numActive, numIdle
and listAllObjects would be good to look at.  Looks like you are
using PoolingDataSource directly, so you need to look at the
underlying GenericObject's JMX properties.

> Thanks,
> Shawn
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message