[ 
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16662119#comment-16662119
 ] 

Mark Struberg commented on POOL-356:
------------------------------------

This is what it looks like in the thread dump.

{noformat}
"Thread-198@1388" daemon prio=5 tid=0xd4 nid=NA waiting
  java.lang.Thread.State: WAITING
          at sun.misc.Unsafe.park(Unsafe.java:-1)
          at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
          at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
          at 
org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:590)
          at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:425)
          at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:346)
          at 
org.apache.commons.pool2.impl.TestGenericObjectPool$TestThread.run(TestGenericObjectPool.java:1680)
          at java.lang.Thread.run(Thread.java:748)

"Thread-197@1387" daemon prio=5 tid=0xd3 nid=NA waiting
  java.lang.Thread.State: WAITING
          at sun.misc.Unsafe.park(Unsafe.java:-1)
          at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
          at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
          at 
org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:590)
          at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:425)
          at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:346)
          at 
org.apache.commons.pool2.impl.TestGenericObjectPool$TestThread.run(TestGenericObjectPool.java:1680)
          at java.lang.Thread.run(Thread.java:748)

"Thread-196@1386" daemon prio=5 tid=0xd2 nid=NA waiting
  java.lang.Thread.State: WAITING
          at sun.misc.Unsafe.park(Unsafe.java:-1)
          at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
          at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
          at 
org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:590)
          at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:425)
          at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:346)
          at 
org.apache.commons.pool2.impl.TestGenericObjectPool$TestThread.run(TestGenericObjectPool.java:1680)
          at java.lang.Thread.run(Thread.java:748)
{noformat}


> deadlock if borrowObject gets called to fast and maxIdle is 0
> -------------------------------------------------------------
>
>                 Key: POOL-356
>                 URL: https://issues.apache.org/jira/browse/POOL-356
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 2.6.0
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>            Priority: Major
>             Fix For: 2.6.1
>
>
> I figured this while creating a unit test for OpenJPA. But also did see this 
> in real production with commons-dbcp2. See DBCP-513 for more info.
> See this comment for a precise explanation what happens 
> https://issues.apache.org/jira/browse/DBCP-513?focusedCommentId=16660545&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16660545
> The problem is basically that the logic to immediately destroy a pool object 
> does not notify the DeLinkedQueue:
> {code}
>         if (isClosed() || maxIdleSave > -1 && maxIdleSave <= 
> idleObjects.size()) {
>             try {
>                 destroy(p);
> {code}
> But the borrowObject code is locking on that condition...
> {code}
>                     if (borrowMaxWaitMillis < 0) {
>                         p = idleObjects.takeFirst();
>                     } 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to