[jira] [Updated] (DBCP-398) DBCP hangs on common pool borrowObject when PoolableConnection is used and the underlying connection closed unexpectedly (connection resets/timouts)

["Sarvesh Sakalanaga (JIRA)" <ji...@apache.org>]

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

Sarvesh Sakalanaga updated DBCP-398:
------------------------------------

    Description: 
The bug is in org.apache.commons.dbcp.PoolableConnection as isClosed method on this calls super.isClosed which returns true (as DelegatingConnection::isClosed { _closed || _conn.isClosed() }). Since PoolableConnection needs to release objects to pool even if the underlying connection is closed the isClosed method should be overridden in this class and should return _closed. This _closed is the delegating connection close which will be set to false even if the underlying connection is closed (_conn.isClosed). The fix should also not throw on PoolableConnection::Close method if underlying connection is closed as this state is a valid state and is expected.

Also currently the way it stands the clients of PoolableConnection will/may not call Close() as isClosed always returns true in this case.

Below is the stack that the thread hangs on:

◾waiting on <0x00000007b5a50e48> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)
 at java.lang.Object.wait(Object.java:503)
 at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104)
◾locked <0x00000007b5a50e48> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)
 at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
 at org.datanucleus.store.rdbms.ConnectionProviderPriorityList.getConnection(ConnectionProviderPriorityList.java:57)
 at org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.getConnection(ConnectionFactoryImpl.java:354)
 at org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.getXAResource(ConnectionFactoryImpl.java:314)
 at org.datanucleus.store.connection.ConnectionManagerImpl.enlistResource(ConnectionManagerImpl.java:386)
 at org.datanucleus.store.connection.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:252)
 at org.datanucleus.store.connection.AbstractConnectionFactory.getConnection(AbstractConnectionFactory.java:60)
 at org.datanucleus.store.AbstractStoreManager.getConnection(AbstractStoreManager.java:449)
 at org.datanucleus.store.AbstractStoreManager.getConnection(AbstractStoreManager.java:418)
 at org.datanucleus.store.rdbms.query.JDOQLQuery.performExecute(JDOQLQuery.java:595)


  was:
The bug is in org.apache.commons.dbcp.PoolableConnection as isClosed method on this calls super.isClosed which returns true (as DelegatingConnection::isClosed { _closed || _conn.isClosed() }). Since PoolableConnection needs to release objects to pool even if the underlying connection is closed the isClosed method should be overridden in this class and should return _closed. This _closed is the delegating connection close which will be set to false even if the underlying connection is closed (_conn.isClosed). The fix should also not throw on PoolableConnection::Close method if underlying connection is closed as this state is a valid state and is expected.

Below is the stack that the thread hangs on:

◾waiting on <0x00000007b5a50e48> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)
 at java.lang.Object.wait(Object.java:503)
 at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104)
◾locked <0x00000007b5a50e48> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)
 at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
 at org.datanucleus.store.rdbms.ConnectionProviderPriorityList.getConnection(ConnectionProviderPriorityList.java:57)
 at org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.getConnection(ConnectionFactoryImpl.java:354)
 at org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.getXAResource(ConnectionFactoryImpl.java:314)
 at org.datanucleus.store.connection.ConnectionManagerImpl.enlistResource(ConnectionManagerImpl.java:386)
 at org.datanucleus.store.connection.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:252)
 at org.datanucleus.store.connection.AbstractConnectionFactory.getConnection(AbstractConnectionFactory.java:60)
 at org.datanucleus.store.AbstractStoreManager.getConnection(AbstractStoreManager.java:449)
 at org.datanucleus.store.AbstractStoreManager.getConnection(AbstractStoreManager.java:418)
 at org.datanucleus.store.rdbms.query.JDOQLQuery.performExecute(JDOQLQuery.java:595)


    
> DBCP hangs on common pool borrowObject when PoolableConnection is used and the underlying connection closed unexpectedly (connection resets/timouts)
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DBCP-398
>                 URL: https://issues.apache.org/jira/browse/DBCP-398
>             Project: Commons Dbcp
>          Issue Type: Bug
>            Reporter: Sarvesh Sakalanaga
>
> The bug is in org.apache.commons.dbcp.PoolableConnection as isClosed method on this calls super.isClosed which returns true (as DelegatingConnection::isClosed { _closed || _conn.isClosed() }). Since PoolableConnection needs to release objects to pool even if the underlying connection is closed the isClosed method should be overridden in this class and should return _closed. This _closed is the delegating connection close which will be set to false even if the underlying connection is closed (_conn.isClosed). The fix should also not throw on PoolableConnection::Close method if underlying connection is closed as this state is a valid state and is expected.
> Also currently the way it stands the clients of PoolableConnection will/may not call Close() as isClosed always returns true in this case.
> Below is the stack that the thread hangs on:
> ◾waiting on <0x00000007b5a50e48> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)
>  at java.lang.Object.wait(Object.java:503)
>  at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104)
> ◾locked <0x00000007b5a50e48> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)
>  at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
>  at org.datanucleus.store.rdbms.ConnectionProviderPriorityList.getConnection(ConnectionProviderPriorityList.java:57)
>  at org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.getConnection(ConnectionFactoryImpl.java:354)
>  at org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.getXAResource(ConnectionFactoryImpl.java:314)
>  at org.datanucleus.store.connection.ConnectionManagerImpl.enlistResource(ConnectionManagerImpl.java:386)
>  at org.datanucleus.store.connection.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:252)
>  at org.datanucleus.store.connection.AbstractConnectionFactory.getConnection(AbstractConnectionFactory.java:60)
>  at org.datanucleus.store.AbstractStoreManager.getConnection(AbstractStoreManager.java:449)
>  at org.datanucleus.store.AbstractStoreManager.getConnection(AbstractStoreManager.java:418)
>  at org.datanucleus.store.rdbms.query.JDOQLQuery.performExecute(JDOQLQuery.java:595)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira