commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [VOTE] Release DBCP 1.3/1.4
Date Wed, 23 Dec 2009 15:40:20 GMT
Jörg Schaible wrote:
> Hi Phil,
> 
> Phil Steitz wrote:
> 
>> Jörg Schaible wrote:
> 
> [snip]
> 
>>> I've modified the trunk and 1.3-branch now. In the 1.3 branch both JOCL
>>> tests set the SAX driver explicitly now and the used xerces artifact has
>>> been harmonized between Ant and Maven build. Also the proper xml-apis is
>>> used now. In trunk I dropped the XML dependencies and the explicit
>>> setting in the JOCL test completely, since it runs OOTB with Java 6. I
>>> also adjusted the 1.3 pom and build.properties.sample in trunk. However,
>>> I wonder if we should drop this anyway, because you cannot build 1.3 from
>>> trunk anyway (mvn -f pom-1.3.pom), because of the dropped source
>>> filtering for the JDBC 3/4 stuff. Changes from trunk can wait for the
>>> next release though.
>> What I am trying to maintain here is a simple way to just cut a
>> branch from trunk and then make some simple changes (see
>> release-process.txt) to cut a 1.3.x release.
> 
> OK.
> 
>> I would *really* like
>> to avoid having to individually back port changes to the 1.3 branch.
>> So I need somehow to isolate the required changes to either
>> filtering or 1.3-compat config files.  I am inclined to just mark
>> the TestJOCLed stuff for filtering.
> 
> We could explicitly set the SAX driver in the two JOCL tests if running with 
> Java 5 or lower. That would keep a single source.

How do we detect the JVM version using maven?  I would be OK with
that, or just filtering out the test altogether.

> 
>>> One last thing: I had one time a NPE that did not result in a failed test
>>> (probably because it happened in a different thread):
>>> ================ %< ===============
>>> Running org.apache.commons.dbcp.datasources.TestSharedPoolDataSource
>>> testMaxWait took 1102 ms
>>> Exception in thread "Thread+33" java.lang.NullPointerException
>>>         at
>>>
> org.apache.commons.dbcp.datasources.TestSharedPoolDataSource$1.uncaughtException(TestSharedPoolDataSource.java:389)
>>> Multithread test time = 645 ms
>>> Multithread test time = 2326 ms
>>> Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.089
>>> sec
>> This is a timing error that occurs sporadically.  The test should be
>> fixed or eliminated.
> 
> There seems another one failing sporadically at Continuum:
> 
> ================== %< ================
> TestPerUserPoolDataSource
>      testMultipleThreads :
>    junit.framework.AssertionFailedError
>    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.dbcp.datasources.TestPerUserPoolDataSource.testMultipleThreads(TestPerUserPoolDataSource.java:377)
> 

Another timing issue.  The setup used in TestPerUserPoolDataSource
and TestSharedPoolDataSource is, well, fragile.  The 1.5.x versions
of pool make it a little worse, since they provide both fairness and
better concurrency.  What is going on in the case above is the pool
is - miraculously - able to successfully serve 2 * maxActive
threads, all of which hold onto their connections for 2 * maxWait
ms. The Continuum instance is running in a VM that does not have the
greatest time resolution.  That combined with thread start and
scheduling variability (and great pool performance ;) can result in
this test failing.

> ================== %< ================
> 
>> Thanks again for your help on this.
> 
> I wish I'd not be always the one reporting the next problem ;-)

Admit it, you love this stuff ;)

Thanks!

Phil



> 
> Cheers,
> Jörg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message