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 13:10:16 GMT
Ah, OK, I had not realised the allocation queue was separate.

GOP does not have a numIdle count - it uses _pool.size() - so is probably OK.

GKOP has a _totalIdle field, but it looks like it is being maintained.

I'll try adding getNumIdle() ==0 checks after all clear() method calls.


On 02/06/2009, Phil Steitz <phil.steitz@gmail.com> wrote:
> 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
>
>

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


Mime
View raw message