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.ste...@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 <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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
