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 <seb...@gmail.com> wrote: > On 02/06/2009, Phil Steitz <phil.ste...@gmail.com> wrote: >> sebb wrote: >> >> > On 02/06/2009, Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org >> > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > >> > > >> > > >> > > >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: >> dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
