Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <772200.54921286638890673.JavaMail.jira@thor>
Date: Sat, 9 Oct 2010 11:41:30 -0400 (EDT)
From: "Kevin Ross (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Issue Comment Edited: (DBCP-345) NumActive is off-by-one at
 instantiation and causes premature exhaustion
In-Reply-To: <16789303.547291286288433376.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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:39 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}

Then look for the first time you see that message.  It proves that numActive is 1 before ever allowing a connection to be borrowed from the pool.

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 AbandonedObjectPool@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.