Re: Proposal - A Very Simple API for Reading Simple XML Data
This should have gone to the dev list.
On May 31, 2009, at 10:33 PM, Ralph Goers wrote:
On May 31, 2009, at 9:24 AM, chris0 wrote:
Hello,
I'm making this proposal because I couldn't find a good solution to a
problem that I recently had.
What I wanted to do was to configure an application with a simple
XML file,
something along the lines of:
test
So the point is that it's really a very simple bit of XML data and
what I
wanted was a nice easy way to read it in. The current options seem
to be
SAX, DOM or JAXB.
Why not just use Commons Configuration and do:
HierarchicalConfiguration config = new XMLConfiguration("config.xml");
String title = config.getString("title");
int majorVersion = config.getInt("versi...@major]");
etc.
Ralph
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] Google App Engine plug-in (GaeVFS)
Great work man.!!! On Sun, May 31, 2009 at 3:25 AM, Vince Bonfanti wrote: > The first public release (0.1) of GaeVFS is now available: > >http://gaevfs.appspot.com/ > > GaeVFS is a plug-in for Apache Commons VFS that implements a virtual file > system on top of the Google App Engine for Java (GAE) datastore. It > provides > a writeable file system for GAE, since GAE does not allow writing to the > local file system. GaeVFS is licensed under the Apache License, Version > 2.0. > > GaeVFS includes a servlet (GaeVfsServlet) that allows you to: > > - upload files into GaeVFS > - serve files from GaeVFS > - (optionally) perform GaeVFS directory listings > > The goal of GaeVFS is to provide a portability layer that allows you to > write application code to access the file system (both reads and writes) > that runs unmodified in either the GAE or "traditional" Java servlet > environments. > > Please let me know if you find this useful. > -- by DILEEP KUMAR.MANDAPAM
Re: [POOL] 1.5-RC2 error in testEviction2
On 31/05/2009, Phil Steitz wrote: > sebb wrote: > > > Just tried testing GKOP using Java 1.6: > > > > java version "1.6.0_13" > > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > > Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) > > > > and I got yet another different error: > > > > > --- > > Test set: > org.apache.commons.pool.impl.TestGenericKeyedObjectPool > > > --- > > Tests run: 43, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: > > 22.703 sec <<< FAILURE! > > > testEviction2(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) > > Time elapsed: 1.203 sec <<< FAILURE! > > junit.framework.AssertionFailedError: Should be less than > 1000 idle, found 1000 > >at junit.framework.Assert.fail(Assert.java:47) > >at > junit.framework.Assert.assertTrue(Assert.java:20) > >at > org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEviction2(TestGenericKeyedObjectPool.java:453) > > > > My system was probably quite busy at the time; I don't know if that is > > relevant or not. > > > > > > This is almost certainly a timing / clock resolution issue. Looks like the > evictor did not kick off in time. I've seen the same error on a quiet system twice now with Java 1.6.0 All the Thread.sleep() calls are enclosed in a try/catch block which ignores InterruptedException, so I suppose it's possible that the test did not wait as long as expected. Since the sleep is an essential part of the test, perhaps the try/catch blocks should be removed, so the test will fail if the sleep fails? > Phil > > > > > S/// > > > > > - > > 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
Re: [pool] 1.5-RC2 available for review
Phil Steitz wrote: sebb wrote: On 31/05/2009, sebb wrote: On 31/05/2009, Phil Steitz wrote: > sebb wrote: > > > On 31/05/2009, Phil Steitz wrote: > > > > > > > sebb wrote: > > > > > > > > > > > > > On 31/05/2009, Phil Steitz 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 item
Re: How to make a proposal
It kind of depends on what you're proposing... a new component? Probably start a discussion on this list. Enhancements to an existing component? Either start here on the list or open a JIRA issue. Does this help? -Matt --- On Sun, 5/31/09, chris0 wrote: > From: chris0 > Subject: How to make a proposal > To: dev@commons.apache.org > Date: Sunday, May 31, 2009, 5:57 AM > > Hello, > > Suppose I wanted to make a proposal for something to be > included in Commons, > is there any particular way I should go about it, or should > I just post it > in this forum? > > Thanks, > > Chris > -- > View this message in context: > http://www.nabble.com/How-to-make-a-proposal-tp23802008p23802008.html > Sent from the Commons - Dev mailing list archive at > Nabble.com. > > > - > 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
Re: [POOL] 1.5-RC2 error in testEviction2
sebb wrote: Just tried testing GKOP using Java 1.6: java version "1.6.0_13" Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) and I got yet another different error: --- Test set: org.apache.commons.pool.impl.TestGenericKeyedObjectPool --- Tests run: 43, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 22.703 sec <<< FAILURE! testEviction2(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 1.203 sec <<< FAILURE! junit.framework.AssertionFailedError: Should be less than 1000 idle, found 1000 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEviction2(TestGenericKeyedObjectPool.java:453) My system was probably quite busy at the time; I don't know if that is relevant or not. This is almost certainly a timing / clock resolution issue. Looks like the evictor did not kick off in time. Phil S/// - 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
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, sebb wrote: > On 31/05/2009, Phil Steitz wrote: > > sebb wrote: > > > > > On 31/05/2009, sebb wrote: > > > > > > > > > > On 31/05/2009, Phil Steitz wrote: > > > > > sebb wrote: > > > > > > > > > > > On 31/05/2009, Phil Steitz wrote: > > > > > > > > > > > > > > > > > > > sebb wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 31/05/2009, Phil Steitz 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
[POOL] 1.5-RC2 error in testEviction2
Just tried testing GKOP using Java 1.6: java version "1.6.0_13" Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) and I got yet another different error: --- Test set: org.apache.commons.pool.impl.TestGenericKeyedObjectPool --- Tests run: 43, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 22.703 sec <<< FAILURE! testEviction2(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 1.203 sec <<< FAILURE! junit.framework.AssertionFailedError: Should be less than 1000 idle, found 1000 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEviction2(TestGenericKeyedObjectPool.java:453) My system was probably quite busy at the time; I don't know if that is relevant or not. S/// - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, Phil Steitz wrote: > sebb wrote: > > > On 31/05/2009, sebb wrote: > > > > > > > On 31/05/2009, Phil Steitz wrote: > > > > sebb wrote: > > > > > > > > > On 31/05/2009, Phil Steitz wrote: > > > > > > > > > > > > > > > > sebb wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On 31/05/2009, Phil Steitz 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 (betwee
Re: [pool] 1.5-RC2 available for review
sebb wrote: On 31/05/2009, sebb wrote: On 31/05/2009, Phil Steitz wrote: > sebb wrote: > > > On 31/05/2009, Phil Steitz wrote: > > > > > > > sebb wrote: > > > > > > > > > > > > > On 31/05/2009, Phil Steitz 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 gues
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, sebb wrote: > On 31/05/2009, Phil Steitz wrote: > > sebb wrote: > > > > > On 31/05/2009, Phil Steitz wrote: > > > > > > > > > > sebb wrote: > > > > > > > > > > > > > > > > > On 31/05/2009, Phil Steitz 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 s
Re: [vfs] Google App Engine plug-in (GaeVFS)
I would be very happy if you could reference it from the Commons VFS web site as a 3rd party plug-in. (Yes, the GaeVFS jar does contain a vfs-providers.xml configuration, so there's no need to add it to providers.xml). On Sun, May 31, 2009 at 2:32 AM, Ralph Goers wrote: > > On May 30, 2009, at 2:55 PM, Vince Bonfanti wrote: > > The first public release (0.1) of GaeVFS is now available: >> >> http://gaevfs.appspot.com/ >> >> GaeVFS is a plug-in for Apache Commons VFS that implements a virtual file >> system on top of the Google App Engine for Java (GAE) datastore. It >> provides >> a writeable file system for GAE, since GAE does not allow writing to the >> local file system. GaeVFS is licensed under the Apache License, Version >> 2.0. >> >> GaeVFS includes a servlet (GaeVfsServlet) that allows you to: >> >> - upload files into GaeVFS >> - serve files from GaeVFS >> - (optionally) perform GaeVFS directory listings >> >> The goal of GaeVFS is to provide a portability layer that allows you to >> write application code to access the file system (both reads and writes) >> that runs unmodified in either the GAE or "traditional" Java servlet >> environments. >> >> Please let me know if you find this useful. >> > > This is kind of cool. My first thought was that it might be nice to include > it in VFS itself, but after looking at > http://code.google.com/appengine/terms.html I have my doubts that > including this at Apache would be doable even as an optional component. > However, I see no reason it couldn't be referenced on the web site and added > to providers.xml to load if it is present. Unless, of course, someone else > has a different opinion. > > Ralph > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: AW: [vfs] Google App Engine plug-in (GaeVFS)
There are two reasons for this: 1. GAE does not set the "os.arch" or "os.version" system properties. When Commons VFS initializes, it tries to do this (OS.java line 36), which throws NullPointerExceptions: * private* *static* *final* String *OS_ARCH* = System.*getProperty*( "os.arch").toLowerCase(Locale.*US*); *private* *static* *final* String *OS_VERSION* = System.*getProperty*( "os.version").toLowerCase(Locale.*US*); The GaeVFS class sets these system properties to avoid the NullPointerExceptions. 2. GAE does not allow background threads, which causes RuntimeExceptions if you try to initialize the default SoftRefFileCache. The GaeVFS class binds in the LRUFilesCache instead. All of this is documented within the GaeVFS source code. On Sun, May 31, 2009 at 10:48 AM, Ralph Goers wrote: > > On May 31, 2009, at 2:44 AM, Mario Ivankovits wrote: > >> >>> >> There is no need to add this to VFS's providers.xml as a vfs plugin is >> able to provides its own vfs-providers.xml [1] which will be loaded by VFS >> then automatically. >> > > Thanks for reminding me. Then I wonder what the requirement that the > application do > > FileSystemManager fsManager = GaeVFS.getManager(); > > is about.
Re: svn commit: r780449 - /commons/proper/pool/trunk/src/test/org/apache/commons/pool/impl/TestGenericKeyedObjectPool.java
sebb wrote:
On 31/05/2009, Phil Steitz wrote:
s...@apache.org wrote:
Thanks!
-for (int i = 0; i < 4; i++) {
+for (int i = 0; i < smallPrimes.length; i++) {
pool.setNumTestsPerEvictionRun(smallPrimes[i]);
-for (int j = 0; j < 5; j++) {
+for (int j = 0; j < 5; j++) { // TODO why 5?
No particular reason to choose 5 here - that is just the number of random
pool-generation-then-visiting iterations to perform. Could make this a
constant, but it is only used here.
OK. I just wondered if it was related to 4==smallPrimes.length.
Perhaps it might be worth making it the outer loop?
Could then make it a variable, e.g. derived from a property, with
default value 5.
This could make the current debugging a bit easier, as we could use a
larger number.
+1
Phil
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
Re: svn commit: r780449 - /commons/proper/pool/trunk/src/test/org/apache/commons/pool/impl/TestGenericKeyedObjectPool.java
On 31/05/2009, Phil Steitz wrote:
> s...@apache.org wrote:
>
> Thanks!
>
> > -for (int i = 0; i < 4; i++) {
> > +for (int i = 0; i < smallPrimes.length; i++) {
> >
> pool.setNumTestsPerEvictionRun(smallPrimes[i]);
> > -for (int j = 0; j < 5; j++) {
> > +for (int j = 0; j < 5; j++) { // TODO why 5?
> >
> >
> No particular reason to choose 5 here - that is just the number of random
> pool-generation-then-visiting iterations to perform. Could make this a
> constant, but it is only used here.
OK. I just wondered if it was related to 4==smallPrimes.length.
Perhaps it might be worth making it the outer loop?
Could then make it a variable, e.g. derived from a property, with
default value 5.
This could make the current debugging a bit easier, as we could use a
larger number.
> 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
Re: svn commit: r780449 - /commons/proper/pool/trunk/src/test/org/apache/commons/pool/impl/TestGenericKeyedObjectPool.java
s...@apache.org wrote:
Thanks!
-for (int i = 0; i < 4; i++) {
+for (int i = 0; i < smallPrimes.length; i++) {
pool.setNumTestsPerEvictionRun(smallPrimes[i]);
-for (int j = 0; j < 5; j++) {
+for (int j = 0; j < 5; j++) { // TODO why 5?
No particular reason to choose 5 here - that is just the number of
random pool-generation-then-visiting iterations to perform. Could make
this a constant, but it is only used here.
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, Phil Steitz wrote: > sebb wrote: > > > On 31/05/2009, Phil Steitz wrote: > > > > > > > sebb wrote: > > > > > > > > > > > > > On 31/05/2009, Phil Steitz 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. > >
Re: AW: [vfs] Google App Engine plug-in (GaeVFS)
On May 31, 2009, at 2:44 AM, Mario Ivankovits wrote: There is no need to add this to VFS's providers.xml as a vfs plugin is able to provides its own vfs-providers.xml [1] which will be loaded by VFS then automatically. Thanks for reminding me. Then I wonder what the requirement that the application do FileSystemManager fsManager = GaeVFS.getManager(); is about.
Re: [pool] 1.5-RC2 available for review
sebb wrote: On 31/05/2009, Phil Steitz wrote: sebb wrote: On 31/05/2009, Phil Steitz 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
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, Phil Steitz wrote: > sebb wrote: > > > On 31/05/2009, sebb wrote: > > > > > > > On 31/05/2009, sebb wrote: > > > > On 31/05/2009, Phil Steitz 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. > > > > > > > > > It failed again after a further 70 or so runs, so if it is a timing > > > issue, the window must be very small. > > > > > > > > > > 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. > > > > > > > > > I'm just working through the Test class now, adding messages where the > > > values are not obvious from the context. > > > > > > > > > > > > > The test failed again (after about 80 retries), and the visitCount for > > the "two" object was 1, whereas the expected value is 2 or 3. > > > > > Is the failure always on the same line of testEvictorVisiting? > So far, yes, it is always line 947 > > > > > > > > == > > > > > > > > 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? > > > > > > > > > > > > > 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
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, Phil Steitz wrote: > sebb wrote: > > > On 31/05/2009, Phil Steitz 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. > 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). > 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.
Re: [pool] 1.5-RC2 available for review
sebb wrote: On 31/05/2009, sebb wrote: On 31/05/2009, sebb wrote: > On 31/05/2009, Phil Steitz 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. It failed again after a further 70 or so runs, so if it is a timing issue, the window must be very small. > 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. I'm just working through the Test class now, adding messages where the values are not obvious from the context. The test failed again (after about 80 retries), and the visitCount for the "two" object was 1, whereas the expected value is 2 or 3. Is the failure always on the same line of testEvictorVisiting? > == > > 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? > > > > 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
Re: [pool] 1.5-RC2 available for review
sebb wrote: On 31/05/2009, Phil Steitz 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
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, sebb wrote: > On 31/05/2009, sebb wrote: > > On 31/05/2009, Phil Steitz 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. > > > It failed again after a further 70 or so runs, so if it is a timing > issue, the window must be very small. > > > > 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. > > > I'm just working through the Test class now, adding messages where the > values are not obvious from the context. > The test failed again (after about 80 retries), and the visitCount for the "two" object was 1, whereas the expected value is 2 or 3. > > == > > > > 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? > > > > > > > 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
[g...@vmgump]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-31052009.jar:/srv/gump/pu blic/workspace/apache-commons/collections/build/commons-collections-31052009.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-31052009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-31052009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-31052009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-31052009.jar:/srv/gump/public/workspace/apache-commons/jexl/dist/commons-jexl-31052009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-31052009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-31052009.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-31052009.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags- fmt-31052009.jar - [junit] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:111) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:267) [junit] ... 11 more [junit] Root cause [junit] java.lang.NoClassDefFoundError: org/apache/tools/ant/Main [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.getProject(AntTagLibrary.java:96) [junit] at org.apache.commons.jelly.tags.ant.AntTag.getAntProject(AntTag.java:310) [junit] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:111) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:267) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:60) [junit] [junit] [junit] Testcase: testSetLocale(org.apache.commons.jelly.
Re: [pool] 1.5-RC2 available for review
Luc Maisonobe wrote: Phil Steitz a écrit : 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! * 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/ There are lots of checkstyle errors (463). However, most of them seem to be missing javadocs for private inner classes, so the missing javadocs are not really important. Yes, I am personally OK with all of these. One error is related to an Apache header in CursorableLinkedList. Most probably some minor white space change or similar as the header is there. I will replace the header. That class was copied from [collections]. These problems are minor to me, so here is my +1. Luc The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ 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
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, sebb wrote: > On 31/05/2009, Phil Steitz 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. It failed again after a further 70 or so runs, so if it is a timing issue, the window must be very small. > 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. I'm just working through the Test class now, adding messages where the values are not obvious from the context. > == > > 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? > > > > 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
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, Phil Steitz 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. == 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? > 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
How to make a proposal
Hello, Suppose I wanted to make a proposal for something to be included in Commons, is there any particular way I should go about it, or should I just post it in this forum? Thanks, Chris -- View this message in context: http://www.nabble.com/How-to-make-a-proposal-tp23802008p23802008.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-configuration-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 110 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/configuration/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/configuration/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html Work Name: build_apache-commons_commons-configuration-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 49 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/configuration] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/configuration/target/commons-configuration-1.7-SNAPSHOT.jar - testAddNodesCopy(org.apache.commons.configuration.TestXMLConfiguration) testInitCopy(org.apache.commons.configuration.TestXMLConfiguration) testSetRootAttribute(org.apache.commons.configuration.TestXMLConfiguration) testLoadAndSaveFromFile(org.apache.commons.configuration.TestXMLConfiguration) testSaveToURL(org.apache.commons.configuration.TestXMLConfiguration) testSaveToStream(org.apache.commons.configuration.TestXMLConfiguration) testAutoSave(org.apache.commons.configuration.TestXMLConfiguration) testSaveAttributes(org.apache.commons.configuration.TestXMLConfiguration) testCloneWithSave(org.apache.commons.configuration.TestXMLConfiguration) testEmptyElements(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithNullEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctype(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctypeIDs(org.apache.commons.configuration.TestXMLConfiguration) testSubsetWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationsAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testGetKeysWithReload(org.apache.commons.configuration.TestXMLConfiguration) testSetTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testClearTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabledAttrs(org.apache.commons.configuration.TestXMLConfiguration) testMultipleAttrValuesEscaped(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithReloadingStrategy(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveAddNodes(org.apache.commons.configuration.TestXMLConfiguration) testAddNodesAndSave(org.apache.commons.configuration.TestXMLConfiguration) testRegisterEntityId(org.apache.commons.configuration.TestXMLConfiguration) testSaveAfterCreateWithCopyConstructor(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootName(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootNameNoDocument(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidation(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidationFailure(org.apache.commons.configuration.TestXMLConfiguration) Tests run: 1419, Failures: 0, Errors: 52, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] -
Re: [cli] New Parser available
Emmanuel,
On Sat, 2009-05-30 at 23:38 +0200, Emmanuel Bourg wrote:
> James Ring a écrit :
>
> > I think partial matching should be disabled by default. While a neat
> > feature to reduce typing, this behaviour will probably come as a
> > surprise to people because it is not found in most programs. Also, if
> > an option is not completely specified, I know I'd like the program to
> > crash rather than run but do something that I don't expect.
>
> I believe a lot a GNU tools implement the partial matching for the long
> options. For example "ls --col" is equivalent to "ls --color". Same
> thing for mysql. But I haven't seen an application supporting the
> partial matching with long options using a single dash ("java -ver"
> doesn't work). I think I'll disable this case by default.
There is a extremely crucial difference between this and the previous
example, this one has -- and so must be handling long options, the
earlier example was -ver.
I would suggest that partial matching of long options with two hyphens
can be on by default since there is no conflict. Partial matching of
long options with single hyphen is much more problematic and so perhaps
should be off by default.
--
Russel.
=
Dr Russel Winder Partner
xmpp: rus...@russel.org.uk
Concertant LLPt: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.win...@ekiga.net
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: [pool] 1.5-RC2 available for review
Phil Steitz a écrit : > 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! > * 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/ There are lots of checkstyle errors (463). However, most of them seem to be missing javadocs for private inner classes, so the missing javadocs are not really important. One error is related to an Apache header in CursorableLinkedList. Most probably some minor white space change or similar as the header is there. These problems are minor to me, so here is my +1. Luc > > The tag is here: > http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ > > 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
AW: [vfs] Google App Engine plug-in (GaeVFS)
Hi! >> http://gaevfs.appspot.com/ cool stuff! > This is kind of cool. My first thought was that it might be nice to > include it in VFS itself, but after looking at > http://code.google.com/appengine/terms.html > I have my doubts that including this at Apache would be doable even > as an optional component. However, I see no reason it couldn't be > referenced on the web site and added to providers.xml to load if it is > present. Unless, of course, someone else has a different opinion. There is no need to add this to VFS's providers.xml as a vfs plugin is able to provides its own vfs-providers.xml [1] which will be loaded by VFS then automatically. Ciao, Mario [1] http://commons.apache.org/vfs/api.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
ss
ss
Re: [pool] 1.5-RC2 available for review
The distribution looks good. If you have to make a 3rd release candidate you may want to add a test on setConfig() and setFactory() in GenericKeyedObjectPool to improve the coverage. But don't hold the release for this. Emmanuel Bourg Phil Steitz a écrit : 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! * 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/ The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ 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
