commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sarvesh Sakalanaga (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DBCP-398) DBCP hangs on common pool borrowObject when PoolableConnection is used and the underlying connection closed unexpectedly (connection resets/timouts)
Date Thu, 23 May 2013 17:41:21 GMT

    [ https://issues.apache.org/jira/browse/DBCP-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13665396#comment-13665396
] 

Sarvesh Sakalanaga commented on DBCP-398:
-----------------------------------------

No the actual problem is with isClosed method. The client code is very simple. It first checks
to see if the PoolableConnection is closed and if its closed it does not call close on it.
No I have not turned on abandoned connection and AFAIK this impacts only  users of PoolableConnection.
                
> 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
>         Attachments: DBCP-398.0.patch
>
>
> 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

Mime
View raw message