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