[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934737#comment-16934737
]
Phil Steitz edited comment on POOL-356 at 9/20/19 8:44 PM:
-----------------------------------------------------------
I am not sure this issue is really valid, but assuming there is a real use case
to have maxIdle set to 0, the committed fix is not correct. create() can
return null and that will result in NPE in the put to idleObjects. If I am
missing something and it really does make sense to have minidle 0 (so you are
basically just using the pool as an object factory), the correct fix is to call
{code:java}
ensureIdle(1, false); {code}
after the call to destroy in returnObject (like it does for validation
failures). That will be a no-op if create returns null.
was (Author: psteitz):
I am not sure this issue is really valid, but assuming there is a real use case
to have maxIdle set to 0, the committed fix is not correct. create() can
return null and that will result in a null object added to the idle queue. If
I am missing something and it really does make sense to have minidle 0 (so you
are basically just using the pool as an object factory), the correct fix is to
call
{code:java}
ensureIdle(1, false); {code}
after the call to destroy in returnObject (like it does for validation
failures). That will be a no-op if create returns null.
> 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
(v8.3.4#803005)
