[
https://issues.apache.org/jira/browse/POOL-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved POOL-85.
----------------------
Resolution: Fixed
Fix Version/s: (was: 2.0)
1.4
> GenericKeyedObjectPool.getNumIdle() corrupted under high load
> -------------------------------------------------------------
>
> Key: POOL-85
> URL: https://issues.apache.org/jira/browse/POOL-85
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Mike Martin
> Fix For: 1.4
>
>
> GenericKeyedObjectPool can have its getNumIdle() value corrupted (as in
> becoming negative) under certain conditions. The conditions appear to be:
> o _maxTotal > 0
> o Multiple keys are in use
> o Objects are borrowed by many threads at a fast rate
> o Demand exceeds _maxTotal
> When _totalIdle gets corrupted then the "pool exhausted" computations are
> compromised, resulting in invalid states such as _totalActive > _maxTotal.
> I've determined the problem originates in ObjectTimestampPair; its compareTo()
> method is not consistent with equals() (see note in java.lang.Comparable docs
> about sorted sets & sorted maps).
> When clearOldest() builds a TreeMap using ObjectTimestampPairs as keys the
> inconsistency with equals can result in OTPs being mapped to the wrong pool
> key if their timestamps are equal. In turn this causes the eventual:
> list.remove(pairTimeStamp);
> at line 902 to silently attempt removal from the wrong list. The OTP doesn't
> get removed but _totalIdle gets decremented.
> Here's the patch:
> --- GenericKeyedObjectPool.java.orig Sun Apr 02 19:59:37 2006
> +++ GenericKeyedObjectPool.java Sun Oct 08 13:32:40 2006
> @@ -1335,7 +1335,12 @@
> }
> public int compareTo(ObjectTimestampPair other) {
> - return (int) (this.tstamp - other.tstamp);
> + int cmp = (int)(this.tstamp - other.tstamp);
> +
> + if (cmp == 0)
> + cmp = System.identityHashCode(this) -
> System.identityHashCode(other);
> +
> + return cmp;
> }
> }
> Mike
--
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
