You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Arie (JIRA)" <ji...@apache.org> on 2007/11/13 02:17:50 UTC
[jira] Created: (DBCP-248) setting maxWait does not work as
expected
setting maxWait does not work as expected
-----------------------------------------
Key: DBCP-248
URL: https://issues.apache.org/jira/browse/DBCP-248
Project: Commons Dbcp
Issue Type: Improvement
Reporter: Arie
My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DBCP-291) setting maxWait does not work as
expected
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz resolved DBCP-291.
------------------------------
Resolution: Fixed
Fixed threadsafety issue in r893809
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: DBCP-291
> URL: https://issues.apache.org/jira/browse/DBCP-291
> Project: Commons Dbcp
> Issue Type: Bug
> Reporter: Arie
> Fix For: 1.3
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (POOL-109) setting maxWait does not
work as expected
Posted by "Arie (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543477 ]
aozarov@hotmail.com edited comment on POOL-109 at 11/19/07 10:00 AM:
------------------------------------------------------
Not sure what did you have in your mind but util.concurrent (if needed) is available as concurrent.util for JDK < 1.5
was (Author: aozarov@hotmail.com):
Not sure what did you have in your mind but util.concurrent (if needed) is available as concurrent.util for JDK < 1.5Regards, Arie Ozarov
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: POOL-109
> URL: https://issues.apache.org/jira/browse/POOL-109
> Project: Commons Pool
> Issue Type: Improvement
> Reporter: Arie
> Fix For: 2.0
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (POOL-109) setting maxWait does not work as
expected
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz updated POOL-109:
-----------------------------
Fix Version/s: 2.0
Improving precision in per-thread timeouts will require more advanced scheduling than is currently available. Best to wait for JDK source level 1.5.
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: POOL-109
> URL: https://issues.apache.org/jira/browse/POOL-109
> Project: Commons Pool
> Issue Type: Improvement
> Reporter: Arie
> Fix For: 2.0
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DBCP-291) setting maxWait does not work as expected
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz closed DBCP-291.
----------------------------
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: DBCP-291
> URL: https://issues.apache.org/jira/browse/DBCP-291
> Project: Commons Dbcp
> Issue Type: Bug
> Reporter: Arie
> Fix For: 1.3
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (POOL-109) setting maxWait does not work as
expected
Posted by "John Bollinger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699932#action_12699932 ]
John Bollinger commented on POOL-109:
-------------------------------------
I tested this against the dev code for 2.0 and 1.5, and both seem to behave as desired already. If multiple threads invoke borrowObject() while the pool is exhausted, then each one waits approximately _maxWait milliseconds before failing with a NoSuchElementException. If they all make their requests at approximately the same time, then the total time for all to finish waiting is also approximately _maxWait milliseconds (not N * _maxWait).
It looks like this issue may have originally been filed against a different project that uses Pool. If the problem persists there then it probably belongs to that project, not to Pool.
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: POOL-109
> URL: https://issues.apache.org/jira/browse/POOL-109
> Project: Commons Pool
> Issue Type: Improvement
> Reporter: Arie
> Fix For: 2.0
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DBCP-291) setting maxWait does not work as
expected
Posted by "Mark Thomas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Thomas resolved DBCP-291.
------------------------------
Resolution: Fixed
Test case added and issue fixed. The fix will be in 1.3 onwards.
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: DBCP-291
> URL: https://issues.apache.org/jira/browse/DBCP-291
> Project: Commons Dbcp
> Issue Type: Bug
> Reporter: Arie
> Fix For: 1.3
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Moved: (DBCP-291) setting maxWait does not work as expected
Posted by "Mark Thomas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Thomas moved POOL-109 to DBCP-291:
---------------------------------------
Fix Version/s: (was: 2.0)
1.3
Issue Type: Bug (was: Improvement)
Key: DBCP-291 (was: POOL-109)
Project: Commons Dbcp (was: Commons Pool)
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: DBCP-291
> URL: https://issues.apache.org/jira/browse/DBCP-291
> Project: Commons Dbcp
> Issue Type: Bug
> Reporter: Arie
> Fix For: 1.3
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (POOL-109) setting maxWait does not work as
expected
Posted by "Arie (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543477 ]
Arie commented on POOL-109:
---------------------------
Not sure what did you have in your mind but util.concurrent (if needed) is available as concurrent.util for JDK < 1.5Regards, Arie Ozarov
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: POOL-109
> URL: https://issues.apache.org/jira/browse/POOL-109
> Project: Commons Pool
> Issue Type: Improvement
> Reporter: Arie
> Fix For: 2.0
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Moved: (POOL-109) setting maxWait does not work as expected
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz moved DBCP-248 to POOL-109:
---------------------------------------
Key: POOL-109 (was: DBCP-248)
Project: Commons Pool (was: Commons Dbcp)
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: POOL-109
> URL: https://issues.apache.org/jira/browse/POOL-109
> Project: Commons Pool
> Issue Type: Improvement
> Reporter: Arie
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-291) setting maxWait does not work as
expected
Posted by "Mark Thomas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710234#action_12710234 ]
Mark Thomas commented on DBCP-291:
----------------------------------
A check of DBCP confirms that getPooledConnectionAndInfo() is indeed a DBCP method so I have moved this issue to DBCP.
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: DBCP-291
> URL: https://issues.apache.org/jira/browse/DBCP-291
> Project: Commons Dbcp
> Issue Type: Bug
> Reporter: Arie
> Fix For: 1.3
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DBCP-291) setting maxWait does not work as
expected
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz reopened DBCP-291:
------------------------------
We need to protect the userkeys map. The uderlying LRUMap impl is not threadsafe. I just got this:
org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool
[junit] at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:183)
[junit] at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:680)
[junit] at org.apache.commons.dbcp.datasources.TestSharedPoolDataSource.getConnection(TestSharedPoolDataSource.java:49)
[junit] at org.apache.commons.dbcp.TestConnectionPool.newConnection(TestConnectionPool.java:84)
[junit] at org.apache.commons.dbcp.TestConnectionPool$TestThread.run(TestConnectionPool.java:595)
[junit] at java.lang.Thread.run(Thread.java:613)
[junit] Caused by: java.lang.NullPointerException
[junit] at org.apache.commons.dbcp.datasources.SequencedHashMap.removeEntry(SequencedHashMap.java:217)
[junit] at org.apache.commons.dbcp.datasources.SequencedHashMap.removeImpl(SequencedHashMap.java:471)
[junit] at org.apache.commons.dbcp.datasources.SequencedHashMap.remove(SequencedHashMap.java:459)
[junit] at org.apache.commons.dbcp.datasources.LRUMap.get(LRUMap.java:97)
[junit] at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getUserPassKey(SharedPoolDataSource.java:203)
[junit] at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:172)
The problem is (I think) caused by concurrent modification to the LRUMap. The get method modifies the map.
> setting maxWait does not work as expected
> -----------------------------------------
>
> Key: DBCP-291
> URL: https://issues.apache.org/jira/browse/DBCP-291
> Project: Commons Dbcp
> Issue Type: Bug
> Reporter: Arie
> Fix For: 1.3
>
>
> My expectation was that if maxWait is set to X seconds and there are N requests waiting to get a connection (in a case where the pool is bounded and
> all the connection are used) if none of the used connection gets free than all N requests will time-out at the same time.
> In reality it seems that 1 request will be timed-out after X seconds the second one after 2 * X and the last one after N * X.
> The problem is that getPooledConnectionAndInfo is synchronized (and therefore will look all N requests) and only one request will be processed at the time.
> This process includes waiting until freed connection or timed-out (done by commons.pool GenericKeyedObjectPool).
> I am not sure why the getPooledConnectionAndInfo has to be synchronized and not only the pool creation part.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.