[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Comment Edited] (POOL-213) _numActive can go negative
From:       "Bruno Candido Volpato da Cunha (JIRA)" <jira () apache ! org>
Date:       2012-11-30 16:07:58
Message-ID: 1801611651.45489.1354291678389.JavaMail.jiratomcat () arcas
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507394#comment-13507394 \
] 

Bruno Candido Volpato da Cunha edited comment on POOL-213 at 11/30/12 4:06 PM:
-------------------------------------------------------------------------------

Hello.

I am having this problem in Commons-Pool 1.6 too...
When I return an Object that doesn't exist in Pool (or even when I return a null), \
the numActive go negative.


{code:title=Test.java|borderStyle=solid}

	@Test
	public void testCommonsPool()  {
		GenericObjectPool<ProgressConnection> pool = \
ProgressConnectionManager.getInstance().getPool();  
		System.out.println(pool.getNumActive());
		
		try {
			ProgressConnection conn = pool.borrowObject();
			pool.returnObject(null); //null or conn have the same behavior
			pool.returnObject(null); //null or conn have the same behavior
		} catch(Exception e) {
			e.printStackTrace();
			
		}
		System.out.println(pool.getNumActive());
		
		
	}
{code} 


The result that I get is:
0
-1
                
      was (Author: brunocvcunha):
    Hello.

I am having this problem in Commons-Pool 1.6 too...
When I return an Object that doesn't exist in Pool (or even when I return a null), \
the numActive go negative.


{code:title=Test.java|borderStyle=solid}

	@Test
	public void testCommonsPool()  {
		GenericObjectPool<ProgressConnection> pool = \
ProgressConnectionManager.getInstance().getPool();  
		System.out.println(pool.getNumActive());
		
		try {
			ProgressConnection conn = pool.borrowObject();
			pool.returnObject(null);
			pool.returnObject(null);
		} catch(Exception e) {
			e.printStackTrace();
			
		}
		System.out.println(pool.getNumActive());
		
		
	}
{code} 


The result that I get is:
0
-1

                  
> _numActive can go negative
> --------------------------
> 
> Key: POOL-213
> URL: https://issues.apache.org/jira/browse/POOL-213
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.5.4
> Reporter: Mark Mindenhall
> 
> I'm working on a project that uses Hector (Cassandra client).  Hector uses \
> commons-pool (we're using 1.5.4) to pool connections to hosts within a Cassandra \
> cluster.  Hector provides a JMX MBean that exposes a "NumActive" property, which is \
> the cumulative call to retrieve numActive from all of the individual connection \
> pools.  When querying this property via JMS on our production servers, we often see \
> negative values.  For example, on a server that has three connection pools, the \
> "NumActive" property reported was -3899. I know this issue has been reported before \
> (POOL-29), and was supposedly fixed.  The fix discussed there was to merely check \
> the value of _numActive to prevent it from going negative.  However, that does not \
> fix the real problem here, which is that it is possible to decrement _numActive \
> more than once for each activated object.   For example, from a quick look at the \
> code (GenericObjectPool.java, v1.5.4), it would be possible to do the following: 1) \
> Create a pool with 10 objects. 2)  Borrow all 10 objects from the pool.
> 3)  Call getNumActive (returns 10).
> 4)  Call invalidateObject for ONE of the objects 11 times.
> 5)  Call getNumActive (returns -1).
> The invalidateObject method calls the _factory to destroy the object, and \
> subsequent calls to destroy the same object may or may not result in an exception.  \
> Regardless, _numActive is decremented within a finally block, and therefore would \
> always be decremented even if the object had already been invalidated and \
> destroyed. I'd like to suggest using a HashSet instead of a counter to keep track \
> of active objects.  If borrowing an object added it to a HashSet, and returning or \
> invaliding the object removed it from the HashSet (subsequent removes would be \
> no-ops), the example given above would not result in an incorrect value when \
> getNumActive is called (it would just return the current size of the HashSet). Note \
> that although unrelated to this bug, it might also be wise to use a HashSet instead \
> of the int counter _numInternalProcessing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[prev in list] [next in list] [prev in thread] [next in thread]