[ https://issues.apache.org/jira/browse/POOL-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Gregory closed POOL-310. ----------------------------- Closing issues for release 2.4.3. Let's create a new issue if we need to adjust [POOL-320] > 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.4.14#64029)