[
https://issues.apache.org/jira/browse/POOL-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Iliev reopened POOL-310:
-----------------------------
Attaching a test case which reproduces the described behaviour.
> Keyed pool usage description correction
> ---------------------------------------
>
> Key: POOL-310
> URL: https://issues.apache.org/jira/browse/POOL-310
> Project: Commons Pool
> Issue Type: Improvement
> Affects Versions: 2.4.2
> Reporter: Ivan Iliev
> Priority: Minor
>
> This applies to GenericKeyedObjectPool.
> Please consider the following situation:
> 1. A pool has been setup to blockWhenExhausted=true
> 2. maxTotal=maxTotalPerKey=1
> 3. no object has yet been added for any key
> 4. two threads are running concurrently
> 5. the first thread borrows key a
> 6. the second thread borrows key b, but fails to create an object as the pool
> is now full, so it gets parked
> 7. the first thread returns the object for its key(a) and also invalidates it
> At this point we must manually unpark the second thread, which is achieved by
> adding a new object for the key b(possibly from the first thread). This
> behaviour is not described in the documentation of the pool. One could assume
> that at step 6, the second thread will block at the object creation and then
> be woken up automatically after returnObject(when the returned object also
> gets invalidated and destroyed).
> Please add this information in the pool's description. Alternativley you
> could enchance the implementation to block at the creation - when the subpool
> is empty and there is no more space, and resume automatically from there,
> without the need of manual object addition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
