You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2013/11/26 00:30:49 UTC
Re: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
unblock threads waiting in borrowObject
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 ;). I have started working on
the tests and fix for GKOP.
Phil
>
> Gary
>
> -------- Original message --------
> From: "Phil Steitz (JIRA)" <ji...@apache.org>
> Date:11/25/2013 18:12 (GMT-05:00)
> To: issues@commons.apache.org
> Subject: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
> unblock threads waiting in borrowObject
>
>
> [ https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832046#comment-13832046 ]
>
> Phil Steitz commented on POOL-240:
> ----------------------------------
>
> Fix for GOP along the lines of what Mark suggested committed in r1545347.
>
>> GKOP: invalidateObject does not unblock threads waiting in borrowObject
>> -----------------------------------------------------------------------
>>
>> Key: POOL-240
>> URL: https://issues.apache.org/jira/browse/POOL-240
>> Project: Commons Pool
>> Issue Type: Bug
>> Affects Versions: 2.0
>> Reporter: Dan McNulty
>> Fix For: 2.0.1
>>
>> Attachments: InvalidateObjectTest.java
>>
>>
>> It appears that when threads are blocked in GKOP.borrowObject due to max object limits being reached and another thread calls invalidateObject, the threads blocked in GKOP.borrowObject are not woken up to attempt to create a new object.
>> Have the semantics changed for invalidate in 2.0?
>> Attached is a unit test that demonstrates this issue. I should note that this test passed against POOL 1.5, after making the appropriate changes due to the API changes in 2.0.
>> After a cursory glance through the source for GenericObjectPool, it looks like it might be affected by the same issue.
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
unblock threads waiting in borrowObject
Posted by Phil Steitz <ph...@gmail.com>.
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
Re: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
unblock threads waiting in borrowObject
Posted by Mark Thomas <ma...@apache.org>.
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.
> 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.
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
Re: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
unblock threads waiting in borrowObject
Posted by Phil Steitz <ph...@gmail.com>.
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.
I am right that destroys on activation or validation failures during
borrow can't trigger this problem, right? 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.
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
Re: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
unblock threads waiting in borrowObject
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
unblock threads waiting in borrowObject
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Nov 25, 2013 at 6:30 PM, Phil Steitz <ph...@gmail.com> 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 ;). I have started working on
> the tests and fix for GKOP.
>
Great, thanks for the update Phil.
Gary
>
> Phil
> >
> > Gary
> >
> > -------- Original message --------
> > From: "Phil Steitz (JIRA)" <ji...@apache.org>
> > Date:11/25/2013 18:12 (GMT-05:00)
> > To: issues@commons.apache.org
> > Subject: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
> > unblock threads waiting in borrowObject
> >
> >
> > [
> https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832046#comment-13832046]
> >
> > Phil Steitz commented on POOL-240:
> > ----------------------------------
> >
> > Fix for GOP along the lines of what Mark suggested committed in r1545347.
> >
> >> GKOP: invalidateObject does not unblock threads waiting in borrowObject
> >> -----------------------------------------------------------------------
> >>
> >> Key: POOL-240
> >> URL: https://issues.apache.org/jira/browse/POOL-240
> >> Project: Commons Pool
> >> Issue Type: Bug
> >> Affects Versions: 2.0
> >> Reporter: Dan McNulty
> >> Fix For: 2.0.1
> >>
> >> Attachments: InvalidateObjectTest.java
> >>
> >>
> >> It appears that when threads are blocked in GKOP.borrowObject due to
> max object limits being reached and another thread calls invalidateObject,
> the threads blocked in GKOP.borrowObject are not woken up to attempt to
> create a new object.
> >> Have the semantics changed for invalidate in 2.0?
> >> Attached is a unit test that demonstrates this issue. I should note
> that this test passed against POOL 1.5, after making the appropriate
> changes due to the API changes in 2.0.
> >> After a cursory glance through the source for GenericObjectPool, it
> looks like it might be affected by the same issue.
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.1#6144)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
>
> Phil
> >
> > Gary
> >
> > -------- Original message --------
> > From: "Phil Steitz (JIRA)" <ji...@apache.org>
> > Date:11/25/2013 18:12 (GMT-05:00)
> > To: issues@commons.apache.org
> > Subject: [jira] [Commented] (POOL-240) GKOP: invalidateObject does not
> > unblock threads waiting in borrowObject
> >
> >
> > [
> https://issues.apache.org/jira/browse/POOL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832046#comment-13832046]
> >
> > Phil Steitz commented on POOL-240:
> > ----------------------------------
> >
> > Fix for GOP along the lines of what Mark suggested committed in r1545347.
> >
> >> GKOP: invalidateObject does not unblock threads waiting in borrowObject
> >> -----------------------------------------------------------------------
> >>
> >> Key: POOL-240
> >> URL: https://issues.apache.org/jira/browse/POOL-240
> >> Project: Commons Pool
> >> Issue Type: Bug
> >> Affects Versions: 2.0
> >> Reporter: Dan McNulty
> >> Fix For: 2.0.1
> >>
> >> Attachments: InvalidateObjectTest.java
> >>
> >>
> >> It appears that when threads are blocked in GKOP.borrowObject due to
> max object limits being reached and another thread calls invalidateObject,
> the threads blocked in GKOP.borrowObject are not woken up to attempt to
> create a new object.
> >> Have the semantics changed for invalidate in 2.0?
> >> Attached is a unit test that demonstrates this issue. I should note
> that this test passed against POOL 1.5, after making the appropriate
> changes due to the API changes in 2.0.
> >> After a cursory glance through the source for GenericObjectPool, it
> looks like it might be affected by the same issue.
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.1#6144)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory