You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Phil Steitz (JIRA)" <ji...@apache.org> on 2015/05/12 15:34:00 UTC

[jira] [Resolved] (POOL-284) "Returned object not currently part of this pool" when using mutable objects

     [ https://issues.apache.org/jira/browse/POOL-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Phil Steitz resolved POOL-284.
------------------------------
       Resolution: Fixed
    Fix Version/s: 2.4

I was not able to consistently measure negative impact associated with the IdentityWrapper modification.  Testing on a 16-way machine with thread counts ranging from 5 - 200, I saw a maximum of 3% reduced throughput (5 threads, one of 5 runs); though on 2 out of 12 runs the IdentityWrapper implementation showed better throughput and in general the difference was less than 1%.  Under higher concurrency (50+ threads), I was able to measure consistent loss of throughput under the StaticBucketMap solution.  I implemented and tested a configurable IdentityWrapper solution; but I was not able to demonstrate consistently better throughput with the configured option turned off.  

So...I decided to commit, in r1678941, the simplest fix, which is non-configurable IdentityWrapper. 

> "Returned object not currently part of this pool" when using mutable objects
> ----------------------------------------------------------------------------
>
>                 Key: POOL-284
>                 URL: https://issues.apache.org/jira/browse/POOL-284
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 2.2
>            Reporter: Valentin Mayamsin
>             Fix For: 2.4
>
>         Attachments: StaticBucketMap-mods.patch, identityWrapper.patch, pool-283-4.patch
>
>
> I'm using pool to reuse expensive Sets (storing millions of items). Here is a test which fails:
> {code}
>         GenericObjectPoolConfig config = new GenericObjectPoolConfig ();
>         GenericObjectPool<Set> aPool = new GenericObjectPool<> ( new BasePooledObjectFactory<Set> ()
>         {
>             @Override
>             public Set create () throws Exception
>             {
>                 return new HashSet();
>             }
>             @Override
>             public PooledObject<Set> wrap ( Set o )
>             {
>                 return new DefaultPooledObject<> ( o );
>             }
>             @Override
>             public void passivateObject ( PooledObject<Set> p ) throws Exception
>             {
>                 p.getObject ().clear ();
>                 super.passivateObject ( p );
>             }
>         }, config );
>         Set set = aPool.borrowObject ();
>         set.add ( new Object () );
>         
>         aPool.returnObject ( set );
> {code}
> This is because GenericObjectPool uses a HashMap<Object, PooledObject> to correlate objects and state. HashMap stores objects correlated to their hashCode. So in case object's state change then hashCode will change, thus Map will fail to correlate this object since it stores old hashCode



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)