commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@apache.org>
Subject Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
Date Mon, 27 Mar 2006 07:15:14 GMT
Anyone up for a game of Clue?

I think testThreading did it, with assertTrue in TestConnectionPool.

On 3/26/06, Phil Steitz <phil.steitz@gmail.com> wrote:
> -0
> Could be a problem with setup or test itself, but with the 1.3-rc4
> jar, I am getting failures in [dbcp] test
> org.apache.commons.dbcp.TestJOCLed.  These tests pass with 1.2.  The
> good news is the other [dbcp] test failures that pool 1.3 is supposed
> to fix succeed for me.  Failures below happen on both Sun Linux JDK
> 1.5.0_06 and 1.4.2_10.
<snip/>
> Checked sigs and contents and everything looks good.  Could be test
> failure is due to bad test in [dbcp].  Will change to +1 when this is
> resolved.
>
> Phil
>
> Test failure:
>
> Testcase: testPooling(org.apache.commons.dbcp.TestJOCLed):      FAILED
> null
> junit.framework.AssertionFailedError
>         at org.apache.commons.dbcp.TestConnectionPool.testPooling(TestConnectionPool.java:270)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
>
> Testcase: testConnectionsAreDistinct(org.apache.commons.dbcp.TestJOCLed):       Caused
> an ERROR
> Cannot get a connection, pool error: Timeout waiting for idle object
> org.apache.commons.dbcp.SQLNestedException: Cannot get a connection,
> pool error: Timeout waiting for idle object
>         at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:183)
>         at java.sql.DriverManager.getConnection(DriverManager.java:525)
>         at java.sql.DriverManager.getConnection(DriverManager.java:193)
>         at org.apache.commons.dbcp.TestJOCLed.getConnection(TestJOCLed.java:42)
>         at org.apache.commons.dbcp.TestConnectionPool.testConnectionsAreDistinct(TestConnectionPool.java:296)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
>         at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:825)
>         at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
>         ... 18 more
>
> This same error occurs for testOpening, testClosing,  testMaxActive,
> testThreaded, testPrepareStatementOptions, testNoRsetClose and
> testHashCode.

Who did it? How did it happen? Lets look at the clues.

First while we are running TestJOCLed, it subclasses
TestConnectionPool and that is where the failures are really
happening.

* testPooling: This test method passes when you run it by itself. It
fails because while it looks like it's written to handle either a FIFO
or a LIFO pool implementation it doesn't if the GenericObjectPool
backing Dbcp has more than 2 idle connections. When the test is run
after other tests the GOP contains 4 idle connections. With a LIFO the
most recently returned is the first one borrowed so it doesn't matter
how many idle connections already exist at the start of the test.
Since GOP is now a FIFO the test fails because is incorrectly assumes
that a recently returned connection will be the next one borrowed. IMO
testPooling should be removed as it really testing Pool's behavior and
not Dbcp's behavior.

* testConnectionsAreDistinct: This test method passes when you run it
by itself. Took me a while to figure out why this fails. It fails
because the GenericObjectPool backing Dbcp is configured with a
maxActive of 10 but for me the test fails after borrowing 9 successful
connections. I'm pretty sure somewhere two of the test methods are
borrowing connections and not following the proper contracts and
closing their connections.

* testOpening, testClosing, testMaxActive, testThreaded,
testPrepareStatemetnOptions, testNoRsetClose, testHashCode: all pass
when run individually. They all fail because when
testConnectionsAreDistinct fails it doesn't close any connection's it
opened in a finally block so the shared GenericObjectPool which has a
maxActive set to 10 thinks it's maxed out with 10 borrowed connections
(9 were from testConnectionsAreDistinct).

This whole unit test class has a problem in that each test method is
not independent of the others. Each test method works when run alone
because they have a fresh state that way. It's when one test leaves
garbage state around after it runs that is affects other tests and
triggers a cascade of failures.

So where is the garbage state coming from? Like I said at the top,
testPooling did it with the assertTrue, specifically lines 270 and 271
of TestConnectionPool:

270: assertTrue( underconn3 == underconn || underconn3 == underconn2 );
271: conn3.close();

When the assertTrue throws an exception the conn3.close is never
called resulting in a connection leak.

The easiest fix is to just transpose those two lines and everything
else but testPooling passes just fine. That still leaves testPooling
as failing and I think that should be solved by removing the test
method completely. I think it's fair to say that unit tests for Pool
belong in the Pool component code base.

Still, someone should look at the testConnectionsAreDistinct test
method as it doesn't clean up after itself when it fails.

Also someone should rework the unit test as a whole so when each test
method is run there is no residual state left over from other test
methods. Until this is fixed TestConnectionPool isn't really testing
what you think it is and probably technically broken.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message