[
https://issues.apache.org/jira/browse/POOL-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Iliev updated POOL-310:
----------------------------
Description:
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)
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 by returnObject(which frees space for a new key's object
to be created).
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 resume automatically from there, without the need of manual object
addition.
was:
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)
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 by returnObject(which frees space for a new key's object
to be created).
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 resume automatically from there, without the need of manual object addition.
> 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)
> 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 by returnObject(which frees space for a new key's
> object to be created).
> 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 resume automatically from there, without the need of manual
> object addition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
