commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject Re: [pool][performance] Source management question
Date Sat, 25 Dec 2010 14:11:30 GMT
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 think I would still depend on perfo.


Gary

On Dec 25, 2010, at 9:03, "Gary Gregory" <GGregory@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" <phil.steitz@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


Mime
View raw message