[ http://issues.apache.org/jira/browse/POOL-94?page=comments#action_12460100 ] Sandy McArthur commented on POOL-94: ------------------------------------
To fix GOP to prevent this wouldn't be trivial and the code is already hairy. The next release, pool 2.0, will include a composite pool implementation that can be configured to track what you are describing. You can get a nightly build at: http://people.apache.org/builds/jakarta-commons/nightly/commons-pool/ then use code similar to: import org.apache.commons.pool.composite.*; CompositeObjectPoolFactory factory = new CompositeObjectPoolFactory(myPoolableObjectFactory); factory.setTrackingPolicy(TrackingPolicy.REFERENCE); // set other factory settings here ObjectPool pool = factory.newInstance(); now when you return an object that wasn't borrowed from the pool, an exception should be thrown when you return that object. Also if yo think you are leaking objects (borrowing but never returning) use a TrackingPolicy of DEBUG and when you borrow an object but it is garbage collected, the stack trace of when the object was borrowed will be logged. Be warned that both tracking methods are measurably slower than the default: TrackingPolicy.SIMPLE which tracks borrowed objects like GOP currently does, with a simple counter. Personally I'd only use REFERENCE or DEBUG in debug builds but not in production. > GenericObjectPool allows checking in of previously checked in objects > --------------------------------------------------------------------- > > Key: POOL-94 > URL: http://issues.apache.org/jira/browse/POOL-94 > Project: Commons Pool > Issue Type: Bug > Affects Versions: 1.3 > Environment: JDK 1.4.2, web application running under Tomcat 5.0.25 > Reporter: Tim McCollough > Priority: Minor > > I am using GenericObjectPool to store a pool of socket connections. While > debugging the application I noticed that the result of GetNumActive() was > becoming more and more negative, while the GetNumIldle() count was ever > increasing. Further debug showed that my application was returning the same > connection more than once and the GenericObjectPool implementation accepted > the return silently and decremented the active count and incremented the idle > count. > I don't object to GenericObjectPool allowing multiple returns on the same > object, but the bookkeeping problem will lead to bad things happening in the > pool management code. > I am investigating what it would take to fix GenericObjectPool but since I am > inexperienced in these commons projects I don't know what I should do from > here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
