[
https://issues.apache.org/jira/browse/DBCP-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919502#action_12919502
]
Kevin Ross edited comment on DBCP-345 at 10/9/10 11:38 AM:
-----------------------------------------------------------
Before borrowing the first connection, {{numActive}} should report 0 correct?
Do we agree, that if you have never borrowed a connection, numActive should not
be greater than 0, regardless of pool settings?
If we agree, then there is a bug.
My code attached exposes this, I'm not sure why you are not able to use it or
see it. The commons-pool package is commonly used for many things and generic
knowledge of that project is very useful in diagnosing this problem.
Put a breakpoint in the borrowObject() method of the pool object (use your
implementation, or mine), and before the super call to borrowObject() in the
pool packages, inspect the {{numActive}}.
If numActive == 1 before the call to the pool to make the first borrow, there
is a bug. AFTER we borrow the first connection, numActive should be 1.
If you still don't see it, change the line of my code in
DebugConnectionPool.java from:
{code:java}log.debug( "BORROWING: from " + toId( delegate ) + stats( delegate
) );{code}
to:
{code:java}log.debug( "BORROWING: holy cow this is num active before borrowing
a connection!!!!!!!!!!!!!!!!!!!!! " + getNumActive() );{code}
I think that should get you there.
was (Author: rosskevin):
Before borrowing the first connection, {{numActive}} should report 0
correct?
Do we agree, that if you have never borrowed a connection, numActive should not
be greater than 0, regardless of pool settings?
If we agree, then there is a bug.
My code attached exposes this, I'm not sure why you are not able to use it or
see it. The commons-pool package is commonly used for many things and generic
knowledge of that project is very useful in diagnosing this problem.
Put a breakpoint in the borrowObject() method of the pool object (use your
implementation, or mine), and before the super call to borrowObject() in the
pool packages, inspect the {{numActive}}.
If numActive == 1 before the call to the pool to make the first borrow, there
is a bug. AFTER we borrow the first connection, numActive should be 1.
If you still don't see it, change the line of my code in
DebugConnectionPool.java from:
{code:java}log.debug( "BORROWING: from " + toId( delegate ) + stats( delegate
) );{code}
to:
{code:java}log.debug( "BORROWING: holy cow this is num active before borrowing
a connection!!!!!!!!!!!!!!!!!!!!! " + getNumActive();{code}
I think that should get you there.
> 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: 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.
