[jira] [Updated] (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 updated POOL-284:
-
Fix Version/s: (was: 2.4)
2.4.1
> "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.1
>
> 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 aPool = new GenericObjectPool<> ( new
> BasePooledObjectFactory ()
> {
> @Override
> public Set create () throws Exception
> {
> return new HashSet();
> }
> @Override
> public PooledObject wrap ( Set o )
> {
> return new DefaultPooledObject<> ( o );
> }
> @Override
> public void passivateObject ( PooledObject 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 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)
[jira] [Updated] (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 updated POOL-284:
-
Attachment: identityWrapper.patch
Here is another patch to consider, implementing wrapping. Note that there is
no "unwrapping" required - we just need to wrap instances when creating hash
keys.
I have been able to measure a 5-7% decrease in throughput when using
StaticBucketMap, but no consistent decrease with this patch. I don't have a
machine with a lot of cores to test with though. Anyone with interest and
available cores can use the primitive JMH setup I have [here |
https://github.com/psteitz/pool-test]
> "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
> 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 aPool = new GenericObjectPool<> ( new
> BasePooledObjectFactory ()
> {
> @Override
> public Set create () throws Exception
> {
> return new HashSet();
> }
> @Override
> public PooledObject wrap ( Set o )
> {
> return new DefaultPooledObject<> ( o );
> }
> @Override
> public void passivateObject ( PooledObject 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 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)
[jira] [Updated] (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 updated POOL-284:
-
Attachment: StaticBucketMap-mods.patch
Diff showing mods on the original Collections class. Objective was to use
system identity hash codes as hash codes for keys and force reference equality
checks. Also, eliminate dependencies on other Collections classes. This class
could be stripped down further if we decide to go this route.
> "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
> Attachments: StaticBucketMap-mods.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 aPool = new GenericObjectPool<> ( new
> BasePooledObjectFactory ()
> {
> @Override
> public Set create () throws Exception
> {
> return new HashSet();
> }
> @Override
> public PooledObject wrap ( Set o )
> {
> return new DefaultPooledObject<> ( o );
> }
> @Override
> public void passivateObject ( PooledObject 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 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)
[jira] [Updated] (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 updated POOL-284:
-
Attachment: pool-283-4.patch
Some WIP to review and performance test. Passes the (disabled) tests for this
issue and POOL-283. Replaces ConcurrentHashMap with a slightly modified
StaticBucketMap from Commons Collections.
I did not set up configurability; but we could make the allObjects map type
configurable, using something like this patch when the requirements of this
issue and / or pool-283 are required.
> "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
> Attachments: 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 aPool = new GenericObjectPool<> ( new
> BasePooledObjectFactory ()
> {
> @Override
> public Set create () throws Exception
> {
> return new HashSet();
> }
> @Override
> public PooledObject wrap ( Set o )
> {
> return new DefaultPooledObject<> ( o );
> }
> @Override
> public void passivateObject ( PooledObject 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 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)
[jira] [Updated] (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
]
Valentin Mayamsin updated POOL-284:
---
Description:
I'm using pool to reuse expensive Sets (storing millions of items). Here is a
test which fails:
{code}
GenericObjectPoolConfig config = new GenericObjectPoolConfig ();
GenericObjectPool aPool = new GenericObjectPool<> ( new
BasePooledObjectFactory ()
{
@Override
public Set create () throws Exception
{
return new HashSet();
}
@Override
public PooledObject wrap ( Set o )
{
return new DefaultPooledObject<> ( o );
}
@Override
public void passivateObject ( PooledObject 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 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
was:
I'm using pool to reuse expensive Sets (storing millions of items). Here is a
test which fails:
{code}
GenericObjectPoolConfig config = new GenericObjectPoolConfig ();
GenericObjectPool aPool = new GenericObjectPool<> ( new
BasePooledObjectFactory ()
{
@Override
public Set create () throws Exception
{
return Sets.newHashSet ();
}
@Override
public PooledObject wrap ( Set o )
{
return new DefaultPooledObject<> ( o );
}
@Override
public void passivateObject ( PooledObject 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 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
> "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 aPool = new GenericObjectPool<> ( new
> BasePooledObjectFactory ()
> {
> @Override
> public Set create () throws Exception
> {
> return new HashSet();
> }
> @Override
> public PooledObject wrap ( Set o )
> {
> return new DefaultPooledObject<> ( o );
> }
> @Override
> public void passivateObject ( PooledObject 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 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)
