[ 
https://issues.apache.org/jira/browse/POOL-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308096#comment-14308096
 ] 

Thomas Neidhart commented on POOL-284:
--------------------------------------

I have found a paper about performance regression testing. Interestingly, they 
evaluated both, GenericObjectPool and StaticBucketMap:

http://mp.binaervarianz.de/issta2014.pdf

The test code is available here: 
https://github.com/michaelpradel/ConTeGe/tree/SpeedGun

> "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
>
> 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)

Reply via email to