[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz reopened POOL-356:
------------------------------
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 `ensureIdle(1, *false*);` 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)
