Hi Phil, Phil Steitz wrote:
> On 2/15/07, Jörg Schaible <[EMAIL PROTECTED]> 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? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
