[
https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508036#comment-13508036
]
Phil Steitz commented on POOL-213:
----------------------------------
In the 1.x versions of pool, there is no guarantee that GenericObjectPool
counters will maintain integrity when clients violate the pool contract by
returning or invalidating the same object multiple times. See the note in the
javadoc for returnObject. I don't think this is something that can be "fixed"
in the 1.x line, because 1.x pools do not maintain references to objects
checked out to clients. This has been changed in the 2.0 branch. As Thomas
points out, 2.0 will throw in these cases.
As a workaround using the 1.x code, you can either directly use DBCP's
AbandonedObjectPool (which will no-op multiple returns / invalidates) or
imitate the approach there, which is to subclass GOP and add tracking for
checked out objects.
Obviously, the best solution is to fix whatever bug in the client code is
causing the multiple returns or invalidates.
I am inclined to close this as WONTFIX. Alternatively, we put fix version as
2.0 and agree that throwing is acceptable in these cases.
> _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
