[jira] [Comment Edited] (POOL-413) [GOP] Race condition while returning objects. maxIdle is ignored

["Adrien Bernard (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/POOL-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774248#comment-17774248 ] 

Adrien Bernard edited comment on POOL-413 at 10/11/23 10:13 PM:
----------------------------------------------------------------

Hello Phil. Thanks a lot for your answers and guidance. I'm line with what you say, I'll try to prepare a patch in the coming days.

There is a corner case to consider though: It is possible to change the maxIdle config of a GOP pool dynamically. Today the LinkedBlockingDeque does not allow to modify the queue's capacity. It could be easily changed but it will make the commons-pool LinkedBlokingDeque drift further away from the JDK's version abilities. Is it an issue for you ? It also means that in the edge case of a downsizing of the maxIdle config, this would lead to evict and destroy some idle objects if the reserve is full (not done today) and thus reduce the performances of the config change. Is it ok for you ? The other possibilities would be forbid the maxIdle resizing - either completely or in a corner case - but this could be a breaking change..

This makes the transition to the expected branch for the patch as commons-pool 3 is now the master branch. Is it a bug you would like to adress in commons pool 3 only or backport in commons pool 2 ? And would you prefer a patch on the pool 3 master branch, the pool 2 one or both ?

Adrien


was (Author: JIRAUSER301516):
Hello Phil. Thanks a lot for your answers and guidance. I'm line with what you say, I'll try to prepare a patch in the coming days.

There is a corner case to consider though: It is possible to change the maxIdle config of a GOP pool dynamically. Today the LinkedBlockingDeque does not allow to modify the queue's capacity. It could be easily changed but it will make the commons-pool LinkedBlokingDeque drift further away from the JDK's version abilities. Is it an issue for you ? It also means that in the edge case of a downsizing of the maxIdle config, this would lead to evict and destroy some idle objects if the reserve is full (not done today) and thus reduce the performances of the config change. Is it ok for you ? The other possibilities would be forbid the maxIdle resizing - either completely or in a corner case but this could be a breaking change..

This makes the transition to the expected branch for the patch as commons-pool 3 is now the master branch. Is it a bug you would like to adress in commons pool 3 only or backport in commons pool 2 ? And would you prefer a patch on the pool 3 master branch, the pool 2 one or both ?

Adrien

> [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)