On 2/20/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
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 ...
The test is to demonstrate that the "thread leak" reported in DBCP-93 is fixed. From the bug report: "In the BasicDataSource.createDataSource method, if the datasource was previously un-initialized, a new GenericObjectPool (or AbandonedObjectPool depending on configuration) is always instantiated. The GenericObjectPool constructor (and also the call to setTimeBetweenEvictionRunsMillis()) starts a new thread for the Evictor. This thread runs until it's cancel() is called. The problem is that if a SQLException is thrown when the PoolableConnectionFactory is instantiated (like with a bad user/pass), the exception is rethrown, but no attempt is made to clean up the Evictor thread that was started in the GenericObjectPool, so that thread just keeps running forever. Since this happens before the datasource was created, the next call to getConnection() will again attempt to re-initialize the datasource in createDataSource(), and if the same error happens again, another Evictor thread will be left running, -> repeat a few thousand times and it starts to bring down systems." The bug was fixed and the test is to demonstrate that the above scenario does not occur. Before the fix, 10 threads would be orphaned by the test code. Joining and waiting on the threads is an interesting idea. Unfortunately, I don't see any way to get references to them. Any better ideas than the hack-ish solution of allowing the count to be off by one or two would be appreciated. Phil
