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