On 4/11/15 6:29 AM, Shawn Heisey wrote:
> I seem to be having a problem very similar to DBCP-398, using DBCP 2.1
> with MySQL.
>
> https://issues.apache.org/jira/browse/DBCP-398
>
> See the last couple of comments.
>
> I am not familiar with the code, so I can't confirm or refute Phil's
> comment that it looks normal, but I can say this:  The problem came to
> my attention because the program had been deadlocked for several hours,
> with the watchdog thread sending "not updating" alarms about every 15
> minutes.
>
> I've been having occasional problems with deadlocks in this program for
> quite a while.  Those problems were occurring even before I switched
> from dbcp to dbcp2.  Until two days ago, I had not tracked down the
> cause of the deadlock.  I was suprised to see that the problem wasn't in
> my own code.
>
> What other information can I provide to determine whether it's a bug or
> something I've done wrong?

Most likely what is happening is that your application is exhausting
the pool of connections.  The relevant lines in the thread dump you
posted on the ticket are:

at
org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583)
        at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442)

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.  What I would do first is carefully
review the code that borrows, uses and returns connections.  Make
sure it always closes them (including exception paths).  If you
can't find the leak, then consider turning on abandoned connection
cleanup (see the DBCP web page for how to configure that).

Phil
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Reply via email to