commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [POOL] 1.5-RC2 soak test errors
Date Thu, 04 Jun 2009 10:15:34 GMT
On 04/06/2009, Mark Thomas <markt@apache.org> wrote:
> sebb wrote:
>  > On 04/06/2009, Mark Thomas <markt@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.

I do have GKOP r781288; but for some reason the top-level directory
only shows r781225.
Not sure why that is; I did a synch. yesterday.

When I do a synch now, the only outstanding update is build.xml 781690.

>  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.

Yes.

>  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

>
>  Mark
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message