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 Wed, 21 Feb 2007 05:06:29 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:
> >> ============================== %< ==================
> >> 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

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