[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240805#comment-13240805 ]
Mark Mindenhall commented on POOL-213: -------------------------------------- I spoke too soon. The current 1.6 release (that can be downloaded) has exactly the same problem with the invalidateObject method: {code} public void invalidateObject(T obj) throws Exception { try { if (_factory != null) { _factory.destroyObject(obj); } } finally { synchronized (this) { _numActive--; } allocate(); } } {code} When you suggested version 1.6, I looked at the version of GenericObjectPool in trunk, which fixes the problem. What's the status of that release? It looks like a major refactoring (even the package name has changed from org.apache.commons.pool to org.apache.commons.pool2). > _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