Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.192.181 as permitted sender)
Message-ID: <52950948.80602@gmail.com>
Date: Tue, 26 Nov 2013 12:49:12 -0800
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
 unblock threads waiting in borrowObject
References: <9gof278yr2538a29b6lv4ug3.1385421433052@email.android.com>
 <5293DDA9.2010404@gmail.com> <52948F64.5050604@apache.org>
 <5294C9A5.9030703@gmail.com> <52950732.50603@apache.org>
In-Reply-To: <52950732.50603@apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11/26/13, 12:40 PM, Mark Thomas wrote:
> On 26/11/2013 16:17, Phil Steitz wrote:
>> On 11/26/13, 4:09 AM, Mark Thomas wrote:
>>> On 25/11/2013 23:30, Phil Steitz wrote:
>>>> On 11/25/13, 3:17 PM, Gary Gregory wrote:
>>>>> Are we getting a 2.0.1 for this fix?
>>>> GKOP still needs to be fixed to resolve this and the GOP fix needs
>>>> the "TR" part of "CTR" done carefully ;).
>>> The GOP fix looks OK to me.
>>>
>>> Good catch with invalidateObject(). I hadn't noticed that.
>> I just committed a fix for GKOP.  I thought about just changing the
>> returnObject code to always call reuseCapacity instead of
>> immediately returning after destroying an object; but reuseCapacity
>> is a weaker liveness-enabler.  Calling addObject with the key of the
>> instance just destroyed seemed more reliable.
> Patch looks good to me.
>
> I noticed a minor inconsistency in the GOP code that I fixed. It wasn't
> a functional change but I think it helps to have the code as consistent
> as possible to aid understanding.

Thanks for fixing that.  Sorry I missed it.
>
>> I am right that destroys on activation or validation failures during
>> borrow can't trigger this problem, right?
> That shouldn't trigger this problem. If the activation or validation
> fails then that will be followed by a call to create.
>
>> Might be good to add test
>> cases for this in any case.  I will get to that eventually, but if
>> this fix passes review I am OK resolving the issue.
> I'm fine with resolving it too.

OK, thanks.

Phil
>
> Mark
>
>
>> Phil
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org