You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Sandy McArthur (JIRA)" <ji...@apache.org> on 2006/12/21 02:22:22 UTC
[jira] Commented: (POOL-94) GenericObjectPool allows checking in of
previously checked in objects
[ 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org