On 04/06/2009, Phil Steitz <phil.ste...@gmail.com> wrote: > Mark Thomas wrote: > > > sebb wrote: > > > > > > > On 04/06/2009, Mark Thomas <ma...@apache.org> wrote: > > > > > > > > > > sebb wrote: > > > > > I've been running the GKOP and GOP tests repeatedly, and there are > > > > > some tests which still fail now and then: > > > > > > > > > > The following test fails regularly: > > > > > > > > > > > testThreaded1(org.apache.commons.pool.impl.TestGenericObjectPool) > > > > > Time elapsed: 6 sec <<< FAILURE! > > > > > junit.framework.AssertionFailedError: Thread 18 > failed: > > > > > java.util.NoSuchElementException: Timeout waiting > for idle object > > > > > > > > > > even on an otherwise idle system > > > > > > > > > > There are 20 threads competing for 15 objects, with a timeout of > > > > > 1000ms; each thread may hold the object for 50ms. Not quite sure > how > > > > > this can cause the problem unless there is some unfairness in the > > > > > allocation. The same test for GKOP fails much less often, which is > > > > > interesting. > > > > > > > > > > > > I don't seem to be able to repeat this one. > > > > > > > > > > > I need to repeat this with the latest code as well. > > > > > > > > > > > > > In terms of possible > > > > explanations: > > > > - GC pause - unlikely unless you have very little memory available > > > > - OS goes off to do something else? Maybe. But the system is idle. > > > > - bug in fairness allocation? Unlikely. We should see > > > > testBorrowObjectFairness failures if that were the case. > > > > - Something else? > > > > > > > > I'll try reducing the timeout from 1000ms to see if I can create the > > > > same failures you see. > > > > > > > > > I've also seen the following, but only when the system is busy: > > > > > > > > > > > testEvictionOrder(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) > > > > > Time elapsed: 1.36 sec <<< FAILURE! > > > > > junit.framework.AssertionFailedError: expected:<5> > but was:<4> > > > > > > > > > > > > This might be fixed by r781288. Do you still see it? > > > > > > > > > > > > > > > Yes, just tried a run whilst doing an Antivirus scan, and I got: > > > > > > Tests run: 43, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: > > > 34.906 sec <<< FAILURE! > > > > testEvictionOrder(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) > > > Time elapsed: 2.109 sec <<< FAILURE! > > > junit.framework.AssertionFailedError: expected:<5> but > was:<4> > > > at junit.framework.Assert.fail(Assert.java:47) > > > at > junit.framework.Assert.failNotEquals(Assert.java:280) > > > at > junit.framework.Assert.assertEquals(Assert.java:64) > > > at > junit.framework.Assert.assertEquals(Assert.java:198) > > > at > junit.framework.Assert.assertEquals(Assert.java:204) > > > at > org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictionOrder(TestGenericKeyedObjectPool.java:782) > > > at > org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictionOrder(TestGenericKeyedObjectPool.java:704) > > > > > > That's the test with lifo==true. > > > > > > AFAICT, this test is very dependent on the timing - if the thread runs > > > too slowly, it's possible for the idle time of the "one" object to > > > pass the 500ms mark, so the pool.evict() at line 780 can remove the > > > first "one" object. > > > > > > Note: I'm now on revision 781225. > > > > > > > > > > ? r781225 < r781288 and it is r781288 that has the fix. > > > > As things stand currently, it appears that the issues you are seeing are > > the result of timing issues where, for whatever reason, something takes > > long than expected by the test. > > > > I'm happy that timing explains these failures and, subject to reviewing > > the RC of course, would be +1 to release the current pool code as 1.5. > > > > If I haven't said it already, many thanks (to Phil as well) for all your > > help testing this. > > > > As an aside, if pool had some logging, we could me much surer about what > > is going on. Definitely something for 2.0. > > > > > +1 to all above. The eviction tests are too time-sensitive, but that is > not a release blocker, IMO, and I am confident that we have found and fixed > the one real bug identified in RC2. I will cut an RC3 with "final names" in > the artifacts this evening and kick off a release vote.
+1 > Thanks! > > Phil > > > > Mark > > > > > > > > > --------------------------------------------------------------------- > > 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
