[
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.
