[
https://issues.apache.org/jira/browse/POOL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17741381#comment-17741381
]
Sebb commented on POOL-411:
---------------------------
The process of upgrading the lock has an inherent window when other threads can
grab the write lock, and thus change the pool.
Whilst it looks like the original issue has been solved, running tests with a
bigger window would help ensure that there aren't any other such issues
lurking. [Unfortunately a sleep will cause the tests to run longer unless the
loop counts are reduced]
As to rechecking that that object is still in the pool: standard behaviour when
upgrading a lock is to recheck the condition once the write lock is obtained.
In this case, the condition is that 'poolMap.get(k)' does not return null, but
this is not checked.
==
There is another possible issue: the code checks the counts for equality with
zero. If there is a possibility that counts may be decremented incorrectly, the
possibility exists that the count may go negative, and perhaps never equal zero
at the time of testing.
It might make sense to check counts and throw an exception if they ever go
negative.
> NPE when deregistering key at end of borrow
> -------------------------------------------
>
> Key: POOL-411
> URL: https://issues.apache.org/jira/browse/POOL-411
> Project: Commons Pool
> Issue Type: Task
> Affects Versions: 2.11.1
> Reporter: Richard Eckart de Castilho
> Priority: Major
> Fix For: 2.12.0
>
>
> There is a potential for an NPE happening in the finally block of
> borrowObject:
> {noformat}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getNumInterested()"
> because "objectDeque" is null
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:821)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:507)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:350)
>
> {noformat}
> From reading the code, it seems this could happen e.g. if a pool is
> concurrently cleared while a borrow is in progress.
> Not sure what a proper solution here would be. Maybe deregister should
> silently do nothing if poolMap.get(k) returns null?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
