commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] 1.5-RC2 available for review
Date Tue, 02 Jun 2009 11:48:44 GMT
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


Mime
View raw message