Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Fri, 18 Mar 2016 09:55:33 +0000 (UTC)
From: "Mark Thomas (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12946240.1456943948000.58245.1458294933455@Atlassian.JIRA>
In-Reply-To: <JIRA.12946240.1456943948000@Atlassian.JIRA>
References: <JIRA.12946240.1456943948000@Atlassian.JIRA>
 <JIRA.12946240.1456943948780@arcas>
Subject: [jira] [Resolved] (POOL-310) Keyed pool usage description
 correction
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/POOL-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Thomas resolved POOL-310.
------------------------------
       Resolution: Fixed
    Fix Version/s: 2.4.3

Thanks for the test case. I'd missed the code path if the factory destroyed the object.

> 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
>             Fix For: 2.4.3
>
>         Attachments: Test.java
>
>
> 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) and also invalidates it
> 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 after returnObject(when the returned object also gets invalidated and destroyed).
> 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 there is no more space, and resume automatically from there, without the need of manual object addition.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)