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. 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. I
will also look into this and see if I can get it to fail. Thanks again
for your help on this.
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