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: [email protected] For additional commands, e-mail: [email protected]
