Re: [pool][performance] Source management question

[Mark Thomas <ma...@apache.org>]

On 25/12/2010 16:18, Phil Steitz wrote:
> Thanks, Gary!
> 
> On Sat, Dec 25, 2010 at 9:11 AM, Gary Gregory
> <GG...@seagullsoftware.com>wrote:
> 
> Hm. Perfo already depends on pool. It would be less controversial to add the
>> test to perfo but that would not demonstrate the bug in pool itself.
>>
> 
>  I thought about that.  That would amount to attaching a [performance]
> config file to a [pool] JIRA ticket.  That would demonstrate the bug, but
> without a unit test in [pool] itself, we would have no way to ensure that it
> did not resurface.  Also, since [performance] is not released, the config is
> likely to continue to change.
> 
> think I would still depend on perfo.
>>
>> But [performance] is a sandbox component that has not been - and may never
> be - released, so this ends up as us a snapshot dependency, which I would
> like to avoid.

Sorry for coming to this late - I have been away for New Year.

The test - in what ever form - really needs to be in pool to ensure we
don't introduce a regression.

Here is a thought, what about an svn external? It can be pinned to HEAD
or a specific version. However, I'd be hapy with any of the other
solutions you suggested as well.

Mark

> 
> Phil
> 
> 
> 
>> Gary
>>
>> On Dec 25, 2010, at 9:03, "Gary Gregory" <GG...@seagullsoftware.com>
>> wrote:
>>
>>> I would just have this new test depend on [performance] and be done with
>> it.
>>>
>>> Gary
>>>
>>> On Dec 25, 2010, at 0:53, "Phil Steitz" <ph...@gmail.com> wrote:
>>>
>>>> I have found what I think is a bug in GKOP[1] using [performance].  I
>> need
>>>> the functionality in the Waiter and WaiterFactory classes in
>>>> o.a.c.performance.pool to build a test case showing the bug.  Having
>> these
>>>> classes available to pool's unit tests would be good.  I am not sure
>> what
>>>> the best approach is to make these classes available to the [pool] tests
>> and
>>>> would appreciate some advice.  I could just copy them, but I don't like
>> the
>>>> idea of maintaining both versions.  Even if [performance] was a proper
>>>> component and had a release, I don't much like the idea of adding a
>>>> dependency.  I could move them to [pool]'s test package, but then
>>>> [performance] could not access them unless [pool] were to export a test
>>>> jar.  Any ideas?  Thanks in advance.
>>>>
>>>> Phil
>>>>
>>>> [1] For those waiting with baited breath to learn what the bug is, it
>>>> manifests as maxActivePerKey exceeded by one.  This can happen when idle
>>>> instances retrieved from the pool fail validation and destroy has
>>>> non-trivial latency.  The problem is (I think) the result of clearOldest
>> not
>>>> updating the per-key internal processing counts.
>>>
>>> ---------------------------------------------------------------------
>>> 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: [pool][performance] Source management question

[Phil Steitz <ph...@gmail.com>]

On Mon, Jan 3, 2011 at 10:17 AM, Mark Thomas <ma...@apache.org> wrote:

> On 25/12/2010 16:18, Phil Steitz wrote:
> > Thanks, Gary!
> >
> > On Sat, Dec 25, 2010 at 9:11 AM, Gary Gregory
> > <GG...@seagullsoftware.com>wrote:
> >
> > Hm. Perfo already depends on pool. It would be less controversial to add
> the
> >> test to perfo but that would not demonstrate the bug in pool itself.
> >>
> >
> >  I thought about that.  That would amount to attaching a [performance]
> > config file to a [pool] JIRA ticket.  That would demonstrate the bug, but
> > without a unit test in [pool] itself, we would have no way to ensure that
> it
> > did not resurface.  Also, since [performance] is not released, the config
> is
> > likely to continue to change.
> >
> > think I would still depend on perfo.
> >>
> >> But [performance] is a sandbox component that has not been - and may
> never
> > be - released, so this ends up as us a snapshot dependency, which I would
> > like to avoid.
>
> Sorry for coming to this late - I have been away for New Year.
>
> The test - in what ever form - really needs to be in pool to ensure we
> don't introduce a regression.
>
> Here is a thought, what about an svn external? It can be pinned to HEAD
> or a specific version. However, I'd be hapy with any of the other
> solutions you suggested as well.
>
>
Thanks.  Thought of that too, but I don't like externals :) I am going to go
ahead and just add classes with the needed functionality to the [pool] test
tree.   Its not a large amount of code and the [performance] classes can be
stripped down a little.

Phil

> Mark
>
> >
> > Phil
> >
> >
> >
> >> Gary
> >>
> >> On Dec 25, 2010, at 9:03, "Gary Gregory" <GG...@seagullsoftware.com>
> >> wrote:
> >>
> >>> I would just have this new test depend on [performance] and be done
> with
> >> it.
> >>>
> >>> Gary
> >>>
> >>> On Dec 25, 2010, at 0:53, "Phil Steitz" <ph...@gmail.com> wrote:
> >>>
> >>>> I have found what I think is a bug in GKOP[1] using [performance].  I
> >> need
> >>>> the functionality in the Waiter and WaiterFactory classes in
> >>>> o.a.c.performance.pool to build a test case showing the bug.  Having
> >> these
> >>>> classes available to pool's unit tests would be good.  I am not sure
> >> what
> >>>> the best approach is to make these classes available to the [pool]
> tests
> >> and
> >>>> would appreciate some advice.  I could just copy them, but I don't
> like
> >> the
> >>>> idea of maintaining both versions.  Even if [performance] was a proper
> >>>> component and had a release, I don't much like the idea of adding a
> >>>> dependency.  I could move them to [pool]'s test package, but then
> >>>> [performance] could not access them unless [pool] were to export a
> test
> >>>> jar.  Any ideas?  Thanks in advance.
> >>>>
> >>>> Phil
> >>>>
> >>>> [1] For those waiting with baited breath to learn what the bug is, it
> >>>> manifests as maxActivePerKey exceeded by one.  This can happen when
> idle
> >>>> instances retrieved from the pool fail validation and destroy has
> >>>> non-trivial latency.  The problem is (I think) the result of
> clearOldest
> >> not
> >>>> updating the per-key internal processing counts.
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
>
>