[jira] [Reopened] (POOL-411) NPE when deregistering key at end of borrow

["Phil Steitz (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/POOL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Phil Steitz reopened POOL-411:
------------------------------

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)