You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gabor Horvath (JIRA)" <ji...@apache.org> on 2010/04/15 09:50:49 UTC
[jira] Created: (POOL-163) GenericKeyedObjectPool.borrowObject does
not invalidate object if validateObject fails
GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails
--------------------------------------------------------------------------------------
Key: POOL-163
URL: https://issues.apache.org/jira/browse/POOL-163
Project: Commons Pool
Issue Type: Bug
Affects Versions: 1.5.4
Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
Reporter: Gabor Horvath
GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
Scenario:
1.) DB connection put into pool
2.) Attempt to reuse connection (borrowObject)
3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz updated DBCP-331:
-----------------------------
Fix Version/s: 1.4.1
1.3.1
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Fix For: 1.3.1, 1.4.1
>
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858559#action_12858559 ]
Gabor Horvath commented on DBCP-331:
------------------------------------
I attached a new version of GenericKeyedObjectPool; all provided (243) unit tests passed with success. Sorry for not providing diff, currently I do not have it installed.
BorrowObject and allocate changed as follows:
-Latch is used for synchronization in code blocks where latch's mutable members are accessed.
-'this' used for synchronizations where allocation queue is accessed.
-Factory method calls are now outside of synchronized blocks: latch is removed from allocation queue before calling the factory methods to avoid concurrent modifications.
I would highly appreciate your review. Thanks.
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858364#action_12858364 ]
Phil Steitz commented on DBCP-331:
----------------------------------
Gabor: can you post some more info on the DBCP config - in particular, is testOnReturn false, how are maxIdle, minIdle set, is the evictor enabled, and are you using DriverAdaptorCPDS (looks like yes)? Thanks!
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Mark Thomas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857877#action_12857877 ]
Mark Thomas commented on DBCP-331:
----------------------------------
-1 for the patch has currently written. It includes calls to factory methods inside sync blocks which will cause deadlocks as documented in the comments at the top of the class.
It would help reviewers if you provided a little more detail regarding the sequence of events that can lead to a threading problem for issues 1) and 2). It may also help to provide separate patches to address them. As for 3) I will veto any patch based on a 'guess' that there might be a problem or that guesses at what the problem might be. Patches need to be backed up with hard evidence.
The code for this and GenericObjectPool is very similar. If there are issues here, there are probably issue sin GOP that also need to be patched.
For future reference, patches should be provided in diff -u format as this requires significantly less effort to review.
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (POOL-163) GenericKeyedObjectPool.borrowObject
does not invalidate object if validateObject fails
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857328#action_12857328 ]
Gabor Horvath commented on POOL-163:
------------------------------------
Thanks for the quick answer.
Yes, you are right, I also checked the allocate() method. I tried to test where the problem comes from; not sure, however it seems all starts with this validity failure (I just put a printStackTrace into dbcp code):
java.sql.SQLException: PooledConnection was reused, withoutits previous Connection being closed.
at org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl.getConnection(PooledConnectionImpl.java:180)
at org.apache.commons.dbcp.datasources.KeyedCPDSConnectionFactory.validateObject(KeyedCPDSConnectionFactory.java:180)
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1197)
at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:181)
at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:701)
at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:676)
at org.apache.torque.TorqueInstance.getConnection(TorqueInstance.java:912)
at org.apache.torque.Torque.getConnection(Torque.java:314)
at org.apache.torque.util.Transaction.beginOptional(Transaction.java:108)
at org.apache.torque.util.BasePeer.doSelect(BasePeer.java:753)
...
at java.lang.Thread.run(Thread.java:619)
And in a little while:
org.apache.torque.TorqueException: java.sql.SQLException: Invalid state, the Connection object is closed.
at org.apache.torque.util.Transaction.commit(Transaction.java:153)
at org.apache.torque.util.BasePeer.doSelect(BasePeer.java:757)
...
at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.SQLException: Invalid state, the Connection object is closed.
at net.sourceforge.jtds.jdbc.ConnectionJDBC2.checkOpen(ConnectionJDBC2.java:1699)
at net.sourceforge.jtds.jdbc.ConnectionJDBC2.getMetaData(ConnectionJDBC2.java:2293)
at org.apache.commons.dbcp.DelegatingConnection.getMetaData(DelegatingConnection.java:346)
at org.apache.torque.util.Transaction.commit(Transaction.java:144)
... 7 more
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails
> --------------------------------------------------------------------------------------
>
> Key: POOL-163
> URL: https://issues.apache.org/jira/browse/POOL-163
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.5.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858145#action_12858145 ]
Phil Steitz commented on DBCP-331:
----------------------------------
I am feeling stupid now for having moved this to DBCP. While there may be DBCP issues exposed here as well, I concur with Gabor's analysis that GOP, GKOP can fail as follows:
Thread 1: enters borrowObject, creates a latch and puts it into the allocation queue
Thread 1: allocate() does not serve the latch, but does set mayCreate() to true
Thread 1: creates a good new instance, "goodGuy" and assigns it to its latch
Thread 1: enters validateObject
Thread 2: returns an invalid instance, "badGuy"
Thread 2: allocate() serves Thread1's latch with "badGuy"
Thread 1: finishes validateObject successfully, but its latch now carries "badGuy" which is returned to the client
Note that this also effectively leaks "goodGuy."
I don't have a test case to demonstrate this yet and I can't fully explain the stack trace without assuming something else awry in the DBCP code, so the above may be flawed, but it looks to me like this is a pool bug.
IIUC what is going on, it is probably best to rely on the latch's monitor in the fix, "closing" it when it is being served in borrowObject and removing but ignoring it in allocate if it is closed.
Gabor: can you post some more info on the DBCP config - in particular, is testOnReturn false, how are maxIdle, minIdle set, is the evictor enabled, and are you using DriverAdaptorCPDS (looks like yes)? Thanks!
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gabor Horvath updated DBCP-331:
-------------------------------
Attachment: GenericKeyedObjectPool.java
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859246#action_12859246 ]
Gabor Horvath commented on DBCP-331:
------------------------------------
Phil, thanks for your response. I will provide you patches inline with your process maybe on the next week.
Please ignore source files I may upload here, these will be just memo for myself.
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gabor Horvath updated DBCP-331:
-------------------------------
Attachment: (was: GenericKeyedObjectPool.java)
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (POOL-163) GenericKeyedObjectPool.borrowObject does
not invalidate object if validateObject fails
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gabor Horvath updated POOL-163:
-------------------------------
Comment: was deleted
(was: Thanks for the quick answer.
Yes, you are right, I also checked the allocate() method. I tried to test where the problem comes from; not sure, however it seems all starts with this validity failure (I just put a printStackTrace into dbcp code):
java.sql.SQLException: PooledConnection was reused, withoutits previous Connection being closed.
at org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl.getConnection(PooledConnectionImpl.java:180)
at org.apache.commons.dbcp.datasources.KeyedCPDSConnectionFactory.validateObject(KeyedCPDSConnectionFactory.java:180)
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1197)
at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:181)
at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:701)
at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:676)
at org.apache.torque.TorqueInstance.getConnection(TorqueInstance.java:912)
at org.apache.torque.Torque.getConnection(Torque.java:314)
at org.apache.torque.util.Transaction.beginOptional(Transaction.java:108)
at org.apache.torque.util.BasePeer.doSelect(BasePeer.java:753)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelectVillageRecords(BasePFTreePeer.java:390)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelectVillageRecords(BasePFTreePeer.java:362)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelect(BasePFTreePeer.java:331)
at com.barra.cp.bdo.torque.PFTreePeer.readPFTreeByUserId(PFTreePeer.java:143)
at com.barra.cp.bdo.test.DBConnectionTest.run(DBConnectionTest.java:53)
at java.lang.Thread.run(Thread.java:619)
And in a little while:
org.apache.torque.TorqueException: java.sql.SQLException: Invalid state, the Connection object is closed.
at org.apache.torque.util.Transaction.commit(Transaction.java:153)
at org.apache.torque.util.BasePeer.doSelect(BasePeer.java:757)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelectVillageRecords(BasePFTreePeer.java:390)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelectVillageRecords(BasePFTreePeer.java:362)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelect(BasePFTreePeer.java:331)
at com.barra.cp.bdo.torque.PFTreePeer.readPFTreeByUserId(PFTreePeer.java:143)
at com.barra.cp.bdo.test.DBConnectionTest.run(DBConnectionTest.java:53)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.SQLException: Invalid state, the Connection object is closed.
at net.sourceforge.jtds.jdbc.ConnectionJDBC2.checkOpen(ConnectionJDBC2.java:1699)
at net.sourceforge.jtds.jdbc.ConnectionJDBC2.getMetaData(ConnectionJDBC2.java:2293)
at org.apache.commons.dbcp.DelegatingConnection.getMetaData(DelegatingConnection.java:346)
at org.apache.torque.util.Transaction.commit(Transaction.java:144)
... 7 more
)
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails
> --------------------------------------------------------------------------------------
>
> Key: POOL-163
> URL: https://issues.apache.org/jira/browse/POOL-163
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.5.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (DBCP-331) GenericKeyedObjectPool.borrowObject does
not invalidate object if validateObject fails
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz moved POOL-163 to DBCP-331:
---------------------------------------
Project: Commons Dbcp (was: Commons Pool)
Key: DBCP-331 (was: POOL-163)
Affects Version/s: 1.4
1.3
(was: 1.5.4)
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails
> --------------------------------------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.4, 1.3
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857855#action_12857855 ]
Gabor Horvath commented on DBCP-331:
------------------------------------
I went deeper into the commons-pool code and found problematic points:
1.) Creating new object for latch is not synchronized, so there is a probability that other thread overrides the latch pair (GenericKeyedObjectPool:1177)
2.) Allocate() method does not care if the latch pair is already assigned in 1.) (~1245).
3.) I guess latch accesses should be synchronized to avoid latch changes between lines.
I attached my changes, please review if you have time. My tests are passed now.
Thanks a lot.
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857956#action_12857956 ]
Gabor Horvath commented on DBCP-331:
------------------------------------
Thanks for checking. I should have really considered the threading issues, I didn't catch the related comments in header...
Just in nutshell, I had problem with connection pooling. Above layers get connections in invalid state; quite difficult to reproduce this symptom but happens under heavy load. I will try to provide a test application maybe next week.
For 1 and 2 I just checked the code and found that part where new object is created without synchronization; this can have sideeffect in case the latch remains in the allocation queue. As I saw chance for that by tracing, I synchronized it and also changed the allocate method to handle the situation if an object is already assigned to the latch... I try to create patches for these.
Regarding 3.) you are totally right.
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (POOL-163) GenericKeyedObjectPool.borrowObject
does not invalidate object if validateObject fails
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857322#action_12857322 ]
Gabor Horvath commented on POOL-163:
------------------------------------
Thanks for the quick answer.
Yes, you are right, I also checked the allocate() method. I tried to test where the problem comes from; not sure, however it seems all starts with this validity failure (I just put a printStackTrace into dbcp code):
java.sql.SQLException: PooledConnection was reused, withoutits previous Connection being closed.
at org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl.getConnection(PooledConnectionImpl.java:180)
at org.apache.commons.dbcp.datasources.KeyedCPDSConnectionFactory.validateObject(KeyedCPDSConnectionFactory.java:180)
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1197)
at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:181)
at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:701)
at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:676)
at org.apache.torque.TorqueInstance.getConnection(TorqueInstance.java:912)
at org.apache.torque.Torque.getConnection(Torque.java:314)
at org.apache.torque.util.Transaction.beginOptional(Transaction.java:108)
at org.apache.torque.util.BasePeer.doSelect(BasePeer.java:753)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelectVillageRecords(BasePFTreePeer.java:390)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelectVillageRecords(BasePFTreePeer.java:362)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelect(BasePFTreePeer.java:331)
at com.barra.cp.bdo.torque.PFTreePeer.readPFTreeByUserId(PFTreePeer.java:143)
at com.barra.cp.bdo.test.DBConnectionTest.run(DBConnectionTest.java:53)
at java.lang.Thread.run(Thread.java:619)
And in a little while:
org.apache.torque.TorqueException: java.sql.SQLException: Invalid state, the Connection object is closed.
at org.apache.torque.util.Transaction.commit(Transaction.java:153)
at org.apache.torque.util.BasePeer.doSelect(BasePeer.java:757)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelectVillageRecords(BasePFTreePeer.java:390)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelectVillageRecords(BasePFTreePeer.java:362)
at com.barra.cp.bdo.torque.base.BasePFTreePeer.doSelect(BasePFTreePeer.java:331)
at com.barra.cp.bdo.torque.PFTreePeer.readPFTreeByUserId(PFTreePeer.java:143)
at com.barra.cp.bdo.test.DBConnectionTest.run(DBConnectionTest.java:53)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.sql.SQLException: Invalid state, the Connection object is closed.
at net.sourceforge.jtds.jdbc.ConnectionJDBC2.checkOpen(ConnectionJDBC2.java:1699)
at net.sourceforge.jtds.jdbc.ConnectionJDBC2.getMetaData(ConnectionJDBC2.java:2293)
at org.apache.commons.dbcp.DelegatingConnection.getMetaData(DelegatingConnection.java:346)
at org.apache.torque.util.Transaction.commit(Transaction.java:144)
... 7 more
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails
> --------------------------------------------------------------------------------------
>
> Key: POOL-163
> URL: https://issues.apache.org/jira/browse/POOL-163
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.5.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859292#action_12859292 ]
Phil Steitz commented on DBCP-331:
----------------------------------
Thanks. That will make it easier. As I said above, it would also be great if you could explain why each change is necessary and how exactly the current code can fail. The change I called out above - pulling the latch out of the queue each time through the loop - is problematic as it will in general not preserve fairness, which is the reason that the queue is there.
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859129#action_12859129 ]
Phil Steitz commented on DBCP-331:
----------------------------------
Thanks, Gabor. It's hard to evaluate your patch as attached for three reasons.
1) It includes quite a few changes and is not in diff format. It would make it much easier for us if you could install the subversion client, checkout the code in trunk, and generate a patch using "svn diff" against your checkout. See the instructions here: http://commons.apache.org/patches.html and do not hesitate to ask privately or on the mailing list if you need help getting set up.
2) It would help to explain in more detail why each of the changes is necessary - e.g., the change to add/remove the latch to/from the allocation queue each time through the loop.
3) It would *really* help to have a test case that fails before the patch and succeeds after. Absent this, a clear description of an execution sequence that leads to a problem is necessary. Ideally, this explanation should explain your production stack traces.
Thanks again for reporting the problem that you are seeing and for your suggestions on improving the code.
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz updated DBCP-331:
-----------------------------
Comment: was deleted
(was: I am feeling stupid now for having moved this to DBCP. While there may be DBCP issues exposed here as well, I concur with Gabor's analysis that GOP, GKOP can fail as follows:
Thread 1: enters borrowObject, creates a latch and puts it into the allocation queue
Thread 1: allocate() does not serve the latch, but does set mayCreate() to true
Thread 1: creates a good new instance, "goodGuy" and assigns it to its latch
Thread 1: enters validateObject
Thread 2: returns an invalid instance, "badGuy"
Thread 2: allocate() serves Thread1's latch with "badGuy"
Thread 1: finishes validateObject successfully, but its latch now carries "badGuy" which is returned to the client
Note that this also effectively leaks "goodGuy."
I don't have a test case to demonstrate this yet and I can't fully explain the stack trace without assuming something else awry in the DBCP code, so the above may be flawed, but it looks to me like this is a pool bug.
IIUC what is going on, it is probably best to rely on the latch's monitor in the fix, "closing" it when it is being served in borrowObject and removing but ignoring it in allocate if it is closed.
Gabor: can you post some more info on the DBCP config - in particular, is testOnReturn false, how are maxIdle, minIdle set, is the evictor enabled, and are you using DriverAdaptorCPDS (looks like yes)? Thanks!)
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz updated DBCP-331:
-----------------------------
Summary: SharedPoolDataSource does not handle null keys correctly (was: GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails)
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gabor Horvath updated DBCP-331:
-------------------------------
Attachment: GenericKeyedObjectPool.java
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (POOL-163) GenericKeyedObjectPool.borrowObject
does not invalidate object if validateObject fails
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857273#action_12857273 ]
Phil Steitz commented on POOL-163:
----------------------------------
Thanks for having a looking into the code, but I think your problem is likely somewhere else. When an object borrowed from the pool fails validation it is destroyed and not returned to the pool. The code is a little complicated, but the object being examined in lines 1195-1228 of the 1.5.4 source is either newly created or has been removed from the pool and assigned to the client thread (i.e. it is no longer in the idle object pool, so will not be returned to the current thread or any other client until it passes validation). The actual removal from the pool happens in the allocate method, where the instance is attached to the latch associated with the client thread.
Can you please provide a stack trace of the exception above?
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails
> --------------------------------------------------------------------------------------
>
> Key: POOL-163
> URL: https://issues.apache.org/jira/browse/POOL-163
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.5.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858411#action_12858411 ]
Gabor Horvath commented on DBCP-331:
------------------------------------
Hi, I use torque, the pool related configurations are:
torque.dsfactory.user.pool.maxActive=-1
torque.dsfactory.user.pool.maxIdle=-1
torque.dsfactory.user.pool.timeBetweenEvictionRunsMillis=30000
torque.dsfactory.user.pool.minEvictableIdleTimeMillis=60000
torque.dsfactory.user.pool.testOnBorrow=true
torque.dsfactory.user.pool.testWhileIdle=false
Other parameters are not specified in my configuration so these should be set to DBCP default (testOnReturn=false, minIdle=0, numTestsPerEvictionRun=3, ...). And yes DriverAdapterCPDS is used via torque. Thanks a lot!
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-331) GenericKeyedObjectPool.borrowObject
does not invalidate object if validateObject fails
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857642#action_12857642 ]
Phil Steitz commented on DBCP-331:
----------------------------------
Thanks for digging into this further. The top stack trace is troubling and may point to a dbcp bug. I don't see anything wrong with the pool part of this, so I moved the issue to dbcp. The torque client is calling getConnection on SharedPoolDataSource with no username or password, which means a <null, null> key (need to look into the torque code to verify that this is normal and what it means). In dbcp 1.4, as part of the changes to support password changes (DBCP-8), equality among UserPassKeys was changed to identify keys with the same username. I don't yet have an explanation for the trace. I will dig into the torque code this weekend and see if I can figure our what is going on.
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails
> --------------------------------------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DBCP-331) SharedPoolDataSource does not handle
null keys correctly
Posted by "Gabor Horvath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859322#action_12859322 ]
Gabor Horvath commented on DBCP-331:
------------------------------------
Partially agree with your comment.
At the point the latch is removed from the allocation queue we can be sure client will be served (assuming validation will be ok):
-if allocation was successful allocated object would be returned
-if allocation failed new object is created
Fairness is broken only in the case if newly created object could not be validated, thus requeueing is needed - this is really a difference. For the remaining scenarios my code works the same I think: if allocation is successful the latch is removed from the queue anyway.
My proposal to fix this problem is to define a new Latch member to show if the latch must be served or not: instead of removing latch from the queue we just set the flag which would be taken into account by allocate(). Method allocate() also would set this flag accordingly instead of removing the latch from queue. Latch would be removed only when borrowObject returns. This way fairness is maintained for the latch lifetime. What do you think?
Thanks for the catch!
> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
> Key: DBCP-331
> URL: https://issues.apache.org/jira/browse/DBCP-331
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
> Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid state, the Connection object is closed"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.