[
https://issues.apache.org/jira/browse/POOL-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047667#comment-18047667
]
Raju Gupta edited comment on POOL-413 at 12/26/25 3:11 PM:
-----------------------------------------------------------
[~psteitz] Added the test to reproduce the behavior. This is a classic check
then act problem. Checking the size and then deleting or adding the object
needs to be atomic. They cannot happen in isolation. There are multiple
pathways to fix this problem.
1) Hold a lock on the idleObjects and then perform the operation.
2) Reverse the operations. Act then check.
I think the second option would help here to solve the issue without acquiring
any additional locks.
A thread will try to optimistically add the pooled objects to the idle set and
then check whether the limit set by the maxIdle is exceeded or not.
Since we are adding and then checking the size, this should be guaranteed to be
a consistent behavior.
The fix would be to just flip the operation as shown below :-
{code:java}
if (getLifo()) {
idleObjects.addFirst(p);
} else {
idleObjects.addLast(p);
}
if (isClosed() || maxIdle > -1 && idleObjects.size() > maxIdle) {
try {
destroy(p, DestroyMode.NORMAL);
} catch (final Exception e) {
swallowException(e);
}
try {
ensureIdle(1, false);
} catch (final Exception e) {
swallowException(e);
}
}
if (isClosed()) {
// Pool closed while object was being added to idle objects.
// Make sure the returned object is destroyed rather than left
// in the idle object pool (which would effectively be a leak)
clear();
}
updateStatsReturn(activeTime); {code}
Let me know what you think.
was (Author: JIRAUSER308107):
[~psteitz] Added the test to reproduce the behavior. This is a classic check
then act problem. Checking the size and then deleting or adding the object
needs to be atomic. They cannot happen in isolation. There are multiple
pathways to fix this problem.
1) Hold a lock on the idleObjects and then perform the operation.
2) Reverse the operations. Act then check.
I think the second option would help here to solve the issue without acquiring
any additional locks.
A thread will try to optimistically add the pooled objects to the idle set and
then check whether the limit set by the maxIdle is exceeded or not.
Since we are adding and then checking the size, this should be guaranteed to be
a consistent behavior.
The fix would be to just flip the operation as shown below :-
{code:java}
if (getLifo()) {
idleObjects.addFirst(p);
} else {
idleObjects.addLast(p);
}
if (isClosed() || maxIdle > -1 && idleObjects.size() > maxIdle) {
try {
destroy(p, DestroyMode.NORMAL);
} catch (final Exception e) {
swallowException(e);
}
try {
ensureIdle(1, false);
} catch (final Exception e) {
swallowException(e);
}
}
if (isClosed()) {
// Pool closed while object was being added to idle objects.
// Make sure the returned object is destroyed rather than left
// in the idle object pool (which would effectively be a leak)
clear();
}
updateStatsReturn(activeTime); {code}
> [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)
