[
https://issues.apache.org/jira/browse/DBCP-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Ross reopened DBCP-345:
-----------------------------
{quote}There must be something else wrong in the concurrency management or
elsewhere in your code.{quote}
Phil, I would encourage you to ponder the following quote:
{quote}When you see hoof prints, think horses - not zebras.{quote}
When I said it works for me, does it work for you? I was trying to find the
differences in our results. Your immediate resolution as *invalid* was
unnecessary and a bit overzealous. It took me hours to uncover this problem,
and it is my duty as a good member of the community to make sure no one else
has to experience this. Your interaction and communication with me was more
likely to run me off rather than for me to persist and make sure this gets
resolved as a valid defect.
Luckily, I am a persistent bastard. Please understand that you don't know who
is on the other end of an issue. The community member on the other end of an
issue could have knowledge that dwarfs you or me, so don't be so quick to
dismiss the work and contribution.
The problem is with {{ds.setRemoveAbandoned( true );}}.
Here is code that proves the problem, commenting the one line (above) removes
the issue, this is what I was trying to get to when I asked you the question in
my last comment.
{code:ja...@test
public void testRemoveAbandonedAndNumActive() throws Exception {
AssertNumActiveDataSource ds = new AssertNumActiveDataSource();
ds.setDriverClassName( "com.mysql.jdbc.Driver" );
ds.setUrl(
"jdbc:mysql://localhost:3306/unitTest?autoReconnect=true&characterEncoding=utf8&useUnicode=true"
);
ds.setUsername( "unitTest" );
ds.setPassword( "unitTest" );
ds.setDefaultAutoCommit( false );
ds.setTestWhileIdle( true );
ds.setTestOnBorrow( true );
ds.setTestOnReturn( false );
ds.setValidationQuery( "SELECT 1" );
ds.setTimeBetweenEvictionRunsMillis( 5000 );
ds.setMaxActive( 3 );
ds.setMinIdle( 0 );
ds.setMaxWait( 10000 );
ds.setInitialSize( 1 );
ds.setMinEvictableIdleTimeMillis( 30000 );
ds.setRemoveAbandonedTimeout( 60 );
ds.setLogAbandoned( true );
// this exposes the problematic issue with NumActive.
ds.setRemoveAbandoned( true );
ds.getConnection();
}
{code}
> NumActive is off-by-one at instantiation and causes premature exhaustion
> ------------------------------------------------------------------------
>
> Key: DBCP-345
> URL: https://issues.apache.org/jira/browse/DBCP-345
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Kevin Ross
> Attachments: AssertNumActiveDataSource.java,
> DebugBasicDataSource.java, DebugConnectionPool.java
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Scenario: we have some code that we had thought was potentially leaking
> connections. In our unitTest/integrationTest environment, we know we can
> *lock down connections to a total of 2* and a full run should pass. We had
> no such luck with a {{maxActive}} of 2.
> We created/attached a {{DebugBasicDataSource}} which initializes a
> {{DebugConnectionPool}} for logging purposes and delegates into the DBCP
> hierarchy. BTW - consistent use of accessors would have made this a cleaner
> affair ;)
> {code} // num active starts at one! Here is the original unmodified
> log message:
> // BORROWING: from abandonedobjectp...@10f0f6ac (1 of 2) 0
> idle: threadStats[ ]: all-time uniques{ (empty) }
> // SEE! no borrows ever, and the first pre-borrow already has a count
> of 1!{code}
> Before borrowing the first connection - {{numActive}} is 1!
> The gorier details below, I hope they help someone else!
> Constraining the pool was the best way to uncover the leakage.
> Thinking it was our error, we went after our code to find the problem. We
> had such a hard time understanding who was using connections, in which Spring
> context. The confusion stemmed from the fact that our unitTests run against
> REST resources deployed as Jersey components in a Grizzly container. Where
> they using the same connection pool or not? Was the unitTest setup side
> exhausting more connections, or was it leaking on the REST service side.
> Answers:
> 1. Our unitTests executing Jersey with in-VM Grizzly container do indeed
> utilize the same pool (and same Spring context).
> 2. Our unitTest (side) was not using more than one connection for data
> setup, and it returned the connection for reuse.
> 3. Our REST service side was only using one connection, but was a Grizzly
> threaded container and we have AcitveMQ running as well. Practically, one
> server connection could handle everything, but the REST service and ActiveMQ
> listener could potentially claim 2.
> Note, the attached DebugBasicDataSource was quite useful to determine which
> threads were claiming which connections in a leak situation. Certainly do
> not configure it on the production side, but it might be nice to see
> something like this offered up on the DBCP site somewhere to help developers
> find or confirm their misconfiguration or bad code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
