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. BTW, I'm not sure that GOP.clear() is fully implemented - AFAICT it does not reset _allocationQueue, _evictionCursor, _numActive, _numInternalProcessing. There may be others. Likewise for GKOP.clear(). > 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
