commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur (JIRA)" <>
Subject [jira] Commented: (POOL-94) GenericObjectPool allows checking in of previously checked in objects
Date Thu, 21 Dec 2006 01:22:22 GMT
    [ ] 
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:
then use code similar to:

import org.apache.commons.pool.composite.*;

CompositeObjectPoolFactory factory = new CompositeObjectPoolFactory(myPoolableObjectFactory);
// 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:
>             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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message