[
https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492344#comment-13492344
]
Thomas Neidhart commented on POOL-213:
--------------------------------------
I tested the described scenario with the latest trunk version (2.0-SNAPSHOT),
and the behavior is now different:
{noformat}
@Test
public void testNumActive() throws Exception {
pool.setMaxTotal(10);
Object o = null;
for (int i = 0; i < 10; i++) {
o = pool.borrowObject();
}
System.out.println(pool.getNumActive());
for (int i = 0; i < 11; i++) {
pool.invalidateObject(o);
}
System.out.println(pool.getNumActive());
}
{noformat}
An exception is thrown when trying to invalidate an object that has already
been removed from the pool.
Though, there may be a possible race condition in the current invalidateObject
method when different threads try to invalidate the same object, as the method
provides no synchronization at all.
In POOL-125 it is mentioned that this problem has been solved, but I fail to
see how this is done for the re-factored version.
> _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
