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
