[
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
