commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: DBCP deadlock
Date Thu, 12 Nov 2009 17:13:58 GMT
Marc Logemann wrote:
> Hi,
> 
> its a deadlock as also Cyrille pointed out.

No, it isn't.

> There is no exhaustion

Yes there is. Look at the source code for the line you quoted:
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:810)


That is the wait() call in
case WHEN_EXHAUSTED_BLOCK:

Every thread in your thread dump that referenced commons.pool (all six of them)
was stuck at that point. It looks very much like your pool was exhausted
previously or is still exhausted.

> because as i said, there a 3 of 30 DB connections active on the DB
> Server.

Which indicates that you likely have a connection leak.

> I even defined all those *Abandoned Timeouts and stuff w/o any
> difference.

Interesting. I'm surprised you didn't see something in catalina.out. It is
probably worth checking the configuration you were using for that.

> Will try commons-pool 1.4 to see if it solves the problem. I
> am quite sure that 1.4 solves the issue because you cant have a monitor
> on a method thats not syncronized ;-) So lets see how that goes....

It is going to depend on what the root cause is. If you are going to upgrade
then I'd suggest going for the latest (1.5.3) as it fixes a number of dead-lock
issues known to exist in 1.4 as well as offering fairer object allocation. This
should enabled the exhausted pool situation to be handled better. Be aware there
is a known issue in 1.5.3 that will be fixed shortly in 1.5.4.

Mark


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


Mime
View raw message