You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Phil Steitz (Jira)" <ji...@apache.org> on 2023/07/07 15:20:00 UTC
[jira] (POOL-411) NPE when deregistering key at end of borrow
[ https://issues.apache.org/jira/browse/POOL-411 ]
Phil Steitz deleted comment on POOL-411:
----------------------------------
was (Author: psteitz):
The added test case has failed at least once now. I think there is a problem with register/deregister protection of pools. Very low probability, but the following seems like it could happen:
Thread 1
# Enter register
# get the read lock
# get a non-null, existing pool
Thread 2
# Clear the pool
# Deregister and remove it
Thread 1
# Register interest in the now orphaned pool
This may be possible because deregister can escalate to write lock while others are holding read locks. The Thread 2 actions have to happen between two instructions in register (when it gets the pool and when it increments its numInterested).
> 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)