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 Thu, 22 Feb 2007 06:15:48 GMT
On 2/20/07, Jörg Schaible <joerg.schaible@gmx.de> wrote:
>
> Hi Phil,
>
> Phil Steitz wrote:
>
> > 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:


I tested with the latest JRockit Linux releases .12 , .8 respectively and
the tests all passed.  I did see the failure on the 1.5.0.6 release,
though.  I can't find anything like meaningful release notes for JRockit, so
can't tell if this was a bug fix.  Any ideas where to release notes for
JRockit?

Phil

>> ============================== %< ==================
> >> 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?
>
> When I try to run the tests from within Eclipse with the JRockit JDK,
> anything works. OTOH when I tried to run the tests yesterday with Maven
> under heavy load of my machine (compiling KOffice), the test succeeded
> also, but two others were failing :-/ Nevertheless, the test above fails
> on "normal" terms always on my machine with Maven/JRockit, so it at least
> repeatable.
>
> I looked at the test, but it seems I don't grok from a quick look enough
> of
> the internals of dbcp to say anything useful. Since I have some experience
> with other concurrent tests, what about joining the evictor thread and
> wait
> for it to stop (at least for a reasonable time)? If it has a unique name,
> you can address it from the test ...
>
> > 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.
>
> OK, I did not recognized this.
>
> > 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.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

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