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

Reply via email to