commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (POOL-213) _numActive can go negative
Date Wed, 02 May 2012 09:34:51 GMT

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

Mark Thomas commented on POOL-213:
----------------------------------

pool2 is a major refactoring that is close to the first release. I am just going through doing
some clean up (reduce duplication of code and Javadoc, add missing Javadoc, expose some additional
attributes via JMX) with a view to doing a release shortly. The core code is pretty stable
and passes all the unit tests. It isn't a release yet but you are free to build from source.
If you find any problems, they should get fixed pretty quickly.
                
> _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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message