[
https://issues.apache.org/jira/browse/POOL-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047822#comment-18047822
]
Phil Steitz commented on POOL-413:
----------------------------------
I think complete re-engineering is not a bad idea for [pool] 3. The problem is
not so much the data structure, which works fine, but the way we are using it.
Going back to v 1, we have always tried to rely completely on client threads to
invoke factory methods, other than the Evictor shim, and we have used the deque
as a create, delivery and storage buffer. To get good performance (which we
have), we keep factory methods out of sync scope and take some risk on capacity
counters. The createdCount does a good job of limiting the total number of
objects in circulation (arguably the most important), but we have to play
whack-a-mole with the idle count as in this issue. The other big problem with
the setup is the liveness concerns that keep popping up. With nothing but
client threads (and the Evictor) to trigger create-and-push-to-queue, we have
had to add a lot of workarounds. So I would be +1 to rethinking the
architecture for POOL 3, using new thread-spawning constructs to manage factory
methods. For v2, I think we should either just make the changes to use the
LBD capacity limit (can't use it directly, but can use the internal code) or
find ways to handle the issues ad hoc. I think the changes needed to limit
maxIdle would be less than what we have already done to improve notifications.
> [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)
