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 Commons DBCP 1.2.2
Date Sun, 18 Feb 2007 17:56:14 GMT
On 2/15/07, Jörg Schaible <joerg.schaible@gmx.de> wrote:
>
> Hi Phil,
>
> sorry I am late and I downloaded the source package, compiled and run all
> tests in Gentoo Linux with Maven for Sun JDK 1.4.2, Sun JDK 1.5.0,
> Blackdown JDK 1.4.2_03, IBM JDK 1.4.2.7, and IBM JDK 1.5.0.3 and all tests
> run fine for these.
>
> It fails for JRockit 1.4.2.11 and 1.5.0.6 though with:
> ============================== %< ==================
> Testsuite: org.apache.commons.dbcp.TestBasicDataSource
> Tests run: 33, Failures: 1, Errors: 0, Time elapsed: 4,364 sec
>
> Testcase:
> testCreateDataSourceCleanupThreads(
> org.apache.commons.dbcp.TestBasicDataSource):
> FAILED
> expected:<1> but was:<2>
> junit.framework.AssertionFailedError: expected:<1> but was:<2>
>         at
>
> org.apache.commons.dbcp.TestBasicDataSource.testCreateDataSourceCleanupThreads
> (TestBasicDataSource.java:334)
>         at jrockit.reflect.VirtualNativeMethodInvoker.invoke(
> Ljava.lang.Object
> [Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> ============================== %< ==================


Ugh.  The test that is failing is to confirm  the fix for DBCP-93, which is
essentially a thread leak.  In retrospect, it was probably not a good idea
to include a check of the form assertEquals(threadCount, Thread.activeCount()),
as appears in this test, since Thread.activeCount is not really guaranteed
to be accurate.  In the case of JRockit, the docs mention something to the
effect of monitoring threads being spawned periodically.  Before the fix,
the test case would have orphaned 10 threads, post fix JRockit is reporting
one extra thread.  I think it is best to do something to fix this, but am
not sure what would be best.  Eliminating the test is one option, or
changing the test to allow one or two extra threads would also work.  I see
this as a blocker, since this test was introduced in 1.2.2 and the build
should succeed on JRockit.  Any suggestions?


Additionally, you've realized that the complete package is no longer
> compatible with JDK 6? I don't know what we can really do about it, since
> the new JDBC version defines a lot of new methods for java.sql.Statement
> and java.sql.Connection and - even worse - some of those methods have
> arguments or return values only avalable in JDK 6.


This is being tracked as DBCP-191.  We can discuss this post 1.2.2, at which
time we may want to create a separate 1.6 branch and version.

Unless someone comes up with a really clever solution, there's nothing we
> can do about it and this is not even documented somewhere in the release.


Yes, should probably have included DBCP-191 in the "significant open issues"
in the release notes.  I will do that.

Thanks for the feedback and testing.

Phil

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message