[
https://issues.apache.org/jira/browse/POOL-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved POOL-310.
------------------------------
Resolution: Fixed
Fix Version/s: 2.4.3
Thanks for the test case. I'd missed the code path if the factory destroyed the
object.
> 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
> Fix For: 2.4.3
>
> Attachments: Test.java
>
>
> 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)
