sebb wrote:
On 31/05/2009, Phil Steitz <phil.ste...@gmail.com> wrote:
sebb wrote:
On 31/05/2009, Phil Steitz <phil.ste...@gmail.com> wrote:
Thanks to all who provided feedback on RC1.
Changes in RC2
* Fixed copyright date in NOTICE.txt
* Restored development reports
* Improved thread-safety and timing/reliability in GOP, GKOP tests -
thanks, sebb!
Unfortunately not enough, see below...
* Added link to release javadoc in site.xml
* Fixed xml errors in changes.xml
* Added test for ErodingPerKeyKeyedObjectPool
* Changed clirr comparison version from 1.3 to 1.4
* Added missing attributes to sources jar manifest
The files are here:
http://people.apache.org/~psteitz/commons-pool-1.5-RC2/
Source and binary archives agree with each other; hashes and sigs OK.
Unfortunately, I got a new test failure with Java 1.4.2 and Maven:
testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool)
Time elapsed: 0.063 sec <<< FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at
junit.framework.Assert.assertTrue(Assert.java:20)
at
junit.framework.Assert.assertTrue(Assert.java:27)
at
org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947)
at
org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810)
I tried re-running the test, and it was OK. Tried rebuild and retest - OK.
As far as I can tell, that particular test does not use threads or
timers as part of the test case, so that suggests that there might be
a timing/threading issue in the main pool code.
I'll try re-running the test case a few more times to see if I can get
it to go wrong again.
Also, clearly the failure message needs to be enhanced to show which
of the following checks failed:
assertTrue(visitCount >= cycleCount &&
visitCount <= cycleCount + 1);
Unfortunately a lot of the assertions fail to provide any details of
what has gone wrong, which make debugging a lot harder.
Thanks for finding and looking into this. Should not be happening. Sorry
the tests in general and this one in particular are so cryptic. What this
one is doing is verifying that the evictor visits idle instances in the
keyed pools in oldest-to-youngest order and does not systematically miss
any. What would be good to know at the time of the failure above is the
values of the local variables visitCount, cycleCount and totalInstances.
Probably also the values of the enclosing loop counts.
It would perhaps be useful to not fail on the first such error, but
only fail when all the objects have been checked, so one could see how
many objects are not visited the expected number of times.
What is going on in this part of the test is that there are three keyed
pools randomly generated containing a total of totalInstances idle objects.
The evictor is run a random number of times (between 10 and 60) and what we
expect is that each instance in the combined pool will be "visited" either
cycleCount or cycleCount +1 times, where
cycleCount = (runs * pool.getNumTestsPerEvictionRun()) /
totalInstances. That is the assertion that is failing. I don't see off
the top of my head how this can be timing or concurrency-related.
Could there be an issue with checking the age?
I don't know how the ages are compared, but Java time resolution means
multiple objects can be created in the same time slot.
Not in this case. The test that is failing is not looking at age or
"evicting" instances because of age. It is just validating idle objects
in the pool (testWhileIdle = true).
I will
also look into this and see if I can get it to fail. Thanks again for your
help on this.
In case it helps, my DOS script for this is:
call mvn compiler:testCompile
echo Start >>testn.log
:LOOP0
echo %DATE% %TIME% >>testn.log
call mvn -Dtest=TestGenericKeyedObjectPool surefire:test
goto LOOP%ERRORLEVEL%
:LOOP1
type target\surefire-reports\*.txt >>testn.log
call bell
If you are not using Windows, it should be easy to change accordingly
I have also just seen the following error:
Running org.apache.commons.pool.impl.TestGenericKeyedObjectPool
java.util.NoSuchElementException: Timeout waiting for idle object
at
org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1139)
at
org.apache.commons.pool.impl.TestGenericKeyedObjectPool$TestThread.run(TestGenericKeyedObjectPool.java:1339)
at java.lang.Thread.run(Thread.java:534)
I'm working on improving the reporting for this as well (at present
the stack trace only goes to stderr; it would be useful if it was
added to the surefire report).
Thanks. That one could be timing. Pls go ahead and commit your
improvements so we can be looking at the same traces.
Phil
Phil
==
Not sure if this is a problem, but the RELEASE-NOTES etc refer to 1.5-RC2.
The OSGI versions likewise include the RC2.
Does that mean there will need to be another build and vote before
release?
Yes. I will roll a "final" candidate with the artifact name changed (but
tag name still RC-) and we will VOTE on that.
The tag is here:
http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/
I used "Last Changed Rev: 780316"
The differences between the xml files have now disappeared; not sure
what went wrong before.
Also the only difference between the tag and the source archives are
doap and release notes, as expected.
Thanks!
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
---------------------------------------------------------------------
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
