On 31/05/2009, Phil Steitz <phil.ste...@gmail.com> wrote: > 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).
Could the evictor be visiting items in the wrong order? Perhaps favouring one object over another? I guess we'd need to validate all the counts before failing in order to find out. > > > > > > > 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. OK, done. > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
