[
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 commented on POOL-213:
-----------------------------------------------------
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
