[jira] [Commented] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0
[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938031#comment-16938031
]
Gary Gregory commented on POOL-356:
---
[~psteitz]
Please update {{changes.xml}}.
> 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
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> 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=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
(v8.3.4#803005)
[jira] [Commented] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0
[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937440#comment-16937440
]
Mark Struberg commented on POOL-356:
Afair this is for ensuring some of our configuration. In pool you can configure
that a pooled item has a maximum lifespan of n. So if you release the pooled
item we check whether this time is over. And in that case we destroy it and
create a fresh instance instead?
> 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
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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=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
(v8.3.4#803005)
[jira] [Commented] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0
[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935230#comment-16935230
]
M Sazzadul Hoque commented on POOL-356:
---
IMHO, it doesn't make any sense to {{create()}} within {{destroy(p)}}. For
example, {{clear()}} uses {{destroy(p)}} {{}} and it's absurd to create same
number of idle objects again. Even worse, doesn't this lead to an infinite
loop?{{}}
> 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=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
(v8.3.4#803005)
[jira] [Commented] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0
[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1192#comment-1192
]
ASF GitHub Bot commented on POOL-356:
-
Github user asfgit closed the pull request at:
https://github.com/apache/commons-pool/pull/11
> 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=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)
[jira] [Commented] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0
[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16662753#comment-16662753
]
ASF GitHub Bot commented on POOL-356:
-
Github user coveralls commented on the issue:
https://github.com/apache/commons-pool/pull/11
[](https://coveralls.io/builds/19703092)
Coverage increased (+0.3%) to 85.174% when pulling
**016a1f67263fe1cde1d910dc7002d972811951c5 on struberg:POOL-356** into
**d4e0e88227ad91d8c8ef36ba01d656f71c770f83 on apache:master**.
> 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=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)
[jira] [Commented] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0
[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16662754#comment-16662754
]
ASF GitHub Bot commented on POOL-356:
-
Github user coveralls commented on the issue:
https://github.com/apache/commons-pool/pull/11
[](https://coveralls.io/builds/19703092)
Coverage increased (+0.3%) to 85.174% when pulling
**016a1f67263fe1cde1d910dc7002d972811951c5 on struberg:POOL-356** into
**d4e0e88227ad91d8c8ef36ba01d656f71c770f83 on apache:master**.
> 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=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)
[jira] [Commented] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0
[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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)
[jira] [Commented] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0
[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16662112#comment-16662112
]
ASF GitHub Bot commented on POOL-356:
-
GitHub user struberg opened a pull request:
https://github.com/apache/commons-pool/pull/11
POOL-356 add unit test for the deadlock
Please review!
Will ship a first fix candidate soon.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/struberg/commons-pool POOL-356
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-pool/pull/11.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #11
commit 60a041d393c75035e9a63c33723c382ac6f35c30
Author: Mark Struberg
Date: 2018-10-24T10:58:38Z
POOL-356 add unit test for the deadlock
> 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=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)
