[
https://issues.apache.org/jira/browse/POOL-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047701#comment-18047701
]
Raju Gupta commented on POOL-413:
---------------------------------
[~psteitz] I agree with the conclusion here. Essentially, we need a lock that
provides atomicity to the check and delete operation. However the
implementation notes says that
*To prevent possible deadlocks, care has been taken to ensure that no call to a
factory method will occur within a synchronization block.*
The *`destroy()`* call is a call to factory method and thus should not occur
within the synchronization block to prevent possible deadlocks.
This limits our options here.
And that's why, we do not necessarily destroy the same object that we push to
the queue. We try to poll from the queue when it exceeds maxIdle. Once {{poll}}
returns an object, it is removed from the pool, so no other thread can borrow
it while it is being destroyed. This ensures that we never destroy an object
that has been handed out to another thread.
> [GOP] Race condition while returning objects. maxIdle is ignored
> ----------------------------------------------------------------
>
> Key: POOL-413
> URL: https://issues.apache.org/jira/browse/POOL-413
> Project: Commons Pool
> Issue Type: Bug
> Reporter: Adrien Bernard
> Priority: Major
> Attachments:
> 0001-Add-test-to-reproduce-concurrency-issue-when-returni.patch
>
>
> In a GenericObjectPool it is possible to configure a maximum number of idle
> objects to be kept by the pool while they are not in use.
> In unfortunate circumstances, if several threads return an object to the pool
> at the same time, the check on the maximum number of idle objects may be
> dismissed. This results in pool keeping more idle objects than configured.
> I have build a unit test to reproduce the issue. I attach it as a patch made
> on top of release 2.12.0. On my machine it randomly fails with a 10% rate.
> Looking into the source code of the returnObject method of the GOP, it seems
> that there is no synchronisation between the moment the check is made for the
> maxIdle configuration and the moment the object is destroyed :
> {code:java}
> final int maxIdleSave = getMaxIdle();
> if (isClosed() || maxIdleSave > -1 && maxIdleSave <= idleObjects.size()) {
> try {
> destroy(p, DestroyMode.NORMAL);
> } catch (final Exception e) {
> swallowException(e);
> }
> try {
> ensureIdle(1, false);
> } catch (final Exception e) {
> swallowException(e);
> }
> } {code}
> Have you thoughts on this ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
