commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] 1.5-RC2 available for review
Date Tue, 02 Jun 2009 12:42:19 GMT
Sorry for top-post (degraded client ;)

My understanding - which I guess could be made clearer in tha javadoc
- is that clear is an operation on the *idle instance pool* and does
not affect instances checked out or pending requests (allocation
queue). Therefore, numActive should be unchanged by this operation, as
well as latch status, internal processing count, etc. numIdle(*)
should be zero on completion.

On 6/2/09, sebb <sebbaz@gmail.com> wrote:
> On 02/06/2009, Phil Steitz <phil.steitz@gmail.com> wrote:
>> sebb wrote:
>>
>> > On 02/06/2009, Phil Steitz <phil.steitz@gmail.com> wrote:
>> >
>> >
>> > >
>> > >
>> > > >
>> > > > >  >
>> > > > >
>> > > > >
>> > > > > I just tried using the fixed numbers from a failed run (instead
of
>> > > > >  using random ones), and it fails every time with the following
>> > > > >  settings:
>> > > > >
>> > > > >  runs=26
>> > > > >  Lengths=12,12,28
>> > > > >
>> > > > >  So it's clearly some kind of logic error - looks like it occurs
>> where
>> > > > >  "runs" is an exact multiple of "totalInstances".
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > s/multiple/divisor/
>> > > >
>> > > > As an experiment, I tried switching the order of the entries in the
>> > > > smallPrimes array to 3,2,5,7.
>> > > >
>> > > > I expected the test to fail on the second loop, but it did not fail.
>> > > >
>> > > > I think this must mean that pool.clear() does not reset the pool
>> fully.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > >  Bingo!  Clear was not fully clearing the pool.  Should be fixed now.
>> > >
>> > >
>> >
>> > The test with fixed values passed; I'm trying a soak test now.
>> >
>> >
>> >
>> > > Thanks, sebb for hunting this down.
>> > >
>> > >
>> > >
>> >
>> > OK, NP.
>> >
>> > It's just lucky that my first test happened to hit the correct
>> > combination to cause the failure, otherwise we might not have noticed
>> > that there was a problem until much later.
>> >
>> > There probably needs to be a proper test for the clear() function.
>> >
>> >
>>  There is one in TestBaseKeyedObjectPool.   I have not been able to induce
>> a
>> failure there, but am working on it.
>>
>> > BTW, I'm not sure that GOP.clear() is fully implemented - AFAICT it
>> > does not reset _allocationQueue, _evictionCursor, _numActive,
>> > _numInternalProcessing. There may be others.
>> >
>> >
>>  Yes.  That is next to fix.
>>
>> > Likewise for GKOP.clear().
>> >
>> >
>>  I don't think we necessarily want to clear the allocation queue,
>> numActive
>> or numInternalProcessing on clear.  Its contract is just to clear the idle
>> object queue.  The cursors should be reset, but clearing the underlying
>> pools should do that.  Would probably do no harm to do this explicitly.
>
> Ah. The Javadocs are subtly different:
>
> GOP.clear() - Clears any objects sitting idle in the pool.
> GKOP.clear() - Clears the pool, removing all pooled instances.
>
> I presume these mean the same.
>
> I assumed that clear() would reset the instance back to its original state.
> Don't these other variables have to relate to the current pools?
>
>>
>> >
>> >
>> > >  Phil
>> > >
>> > >
>> > >
>> > > >
>> > > >
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > >  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
>
>

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


Mime
View raw message