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