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:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
