March 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5308) Reduce ConcurrentHashMapv8 allocations

by William Burns (JIRA)

William Burns created ISPN-5308: ----------------------------------- Summary: Reduce ConcurrentHashMapv8 allocations Key: ISPN-5308 URL: https://issues.jboss.org/browse/ISPN-5308 Project: Infinispan Issue Type: Enhancement Components: Eviction Affects Versions: 7.2.0.Beta1 Reporter: William Burns Assignee: William Burns The current EquivalentConcurrentHashMapv8 allocates a lot of extra entries for the sake of atomicity. It would be helpful to reduce these allocations if possible. # Whenever a get refreshes an entries recency we have to allocate a new DequeNode. This is because of ConcurrentLinkedDeque not always removing the node (this can happen when the node is a head or tail node. If we are able to detect when the node was removed and reuse it it will drastically reduce how many allocations this uses since a deque should rarely be removed from the head or tail on a get. # The current size and current number of evicting elements is stored as 2 longs in a custom class. We have to use compare and set semantics to keep these correct. If instead we utilized a single long where the top 16 bits are reserved for number of evicting elements (concurrent puts) and used the bottom 48 bits for the actual size we can use a simple AtomicLong instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4842) Reduce the overhead of clustered caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4842?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4842: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1163616 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1163616, https://bugzilla.redhat.com/show_bug.cgi?id=1186874) > Reduce the overhead of clustered caches > --------------------------------------- > > Key: ISPN-4842 > URL: https://issues.jboss.org/browse/ISPN-4842 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: Takayoshi Kimura > > A user is testing 500 nodes cluster with 500 dist caches defined, and plans to expand it to 3000 caches. > Infinispan manages consistent hash per cache, uses a JGroups channel per cache and uses several threads per cache. It gives significant overhead with this large size cluster. When tested with this size, Infinispan easily exhausted all threads in the thread pools and deadlocks, and requires several thousands threads to handle massive JOIN requests - the coord receives 499 * 3000 JOIN requests. > It would be great if we can share the consistent hash and resources between caches. For example, define a "master" dist cache and allow other caches to refer to the master cache for resource sharing. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5147) Creation/configuration of caches using JON should not require a server restart

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5147?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5147: ------------------------------------------ Bugzilla Update: (was: Perform) Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=1186874) > Creation/configuration of caches using JON should not require a server restart > ------------------------------------------------------------------------------ > > Key: ISPN-5147 > URL: https://issues.jboss.org/browse/ISPN-5147 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management, Server > Reporter: Tristan Tarrant > Assignee: William Burns > Fix For: 7.2.0.Final > > > When creating a cache using the management interface, we want to be able to set all specific configuration and start the cache without requiring a server restart. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5307) Cache#remove(key) not behaving correctly under high load - while primary owner node is stopped

by Carsten Lohmann (JIRA)

[ https://issues.jboss.org/browse/ISPN-5307?page=com.atlassian.jira.plugin.... ] Carsten Lohmann updated ISPN-5307: ---------------------------------- Description: In our application we had the problem that under high load a {{Cache#remove(key)}} invocation returned the old value _although_ the same key was already removed on another node a few milliseconds before. This occurred while another node was shutdown - that node happened to be the coordinator and also the primary owner of the key here. The cache is a distributed, DB-persisted, transactional (locking mode Pessimistic) cache with numOwners=1. I could reproduce such an issue with the attached unit test (tested on ISPN 7.1). Scenario: - MultipleCacheManagersTest with 3 nodes - Cache is distributed, persisted, transactional (locking mode Pessimistic) with numOwners 1 or 2 (see below; {{getTestCacheNumOwners()}} in the test) - a number of test keys get inserted; only keys with the coordinator as primary owner get used for the test - while the keys get removed one-by-one and concurrently by 2 threads... - ... the coordinator node gets stopped At the end, the return values of the {{remove()}} invocations get checked. {{remove()}} invocations that threw an error (SuspectException) are ignored. *The following problems occurred on some test runs*: # the {{remove(key)}} invocations on both nodes returned {{null}} and the entry was still there in the end #* => I would have expected an exception here as {{remove(key)}} essentially failed # the {{remove(key)}} invocations on both nodes returned {{null}} but the entry was actually removed #* => wrong return value of first invocation # the {{remove(key)}} invocations on both nodes returned both the old value #* => wrong return value of second invocation These issues occur not always but quite often with the test. When testing with {{numOwners=2}}, I only got the last of the above issues - in the test with {{numOwners=1}} that occurred only rarely. Attached are log files from tests with {{numOwners=1}} ("org.infinispan.transaction" log level set to TRACE): - ~40% of test runs produced: issue 3 ("2 remove() invocations returned the old value for key 'k4'") - occurred rarely: issue 2 ("remove() did actually remove the key 'k4', but the return value was null") - didn't occur with "org.infinispan.transaction" log level set to TRACE; but otherwise quite often: issue 1 ("remove() of key 'k4' did not succeed, but we got no exception (entry still there; value: 'v')") was: In our application we had the problem that under high load a {{Cache#remove(key)}} invocation returned the old value _although_ the same key was already removed on another node a few milliseconds before. This occurred while another node was shutdown - that node happened to be the coordinator and also the primary owner of the key here. The cache is a distributed, DB-persisted, transactional (locking mode Pessimistic) cache with numOwners=1. I could reproduce such an issue with the attached unit test (tested on ISPN 7.1). Scenario: - MultipleCacheManagersTest with 3 nodes - Cache is distributed, persisted, transactional (locking mode Pessimistic) with numOwners 1 or 2 (see below; {{getTestCacheNumOwners()}} in the test) - a number of test keys get inserted; only keys with the coordinator as primary owner get used for the test - while the keys get removed one-by-one and concurrently by 2 threads... - ... the coordinator node gets stopped At the end, the return values of the {{remove()}} invocations get checked. {{remove()}} invocations that threw an error (SuspectException) are ignored. *The following problems occurred on some test runs*: # the {{remove(key)}} invocations on both nodes returned {{null}} and the entry was still there in the end #* => I would have expected an exception here as {{remove(key)}} essentially failed # the {{remove(key)}} invocations on both nodes returned {{null}} but the entry was actually removed #* => wrong return value of first invocation # the {{remove(key)}} invocations on both nodes returned both the old value #* => wrong return value of second invocation These issues occur not always but quite often with the test. When testing with {{numOwners=2}}, I only got the last of the above issues - in the test with {{numOwners=1}} that occurred only rarely. Attached are log files from tests with {{numOwners=1}} ("org.infinispan.transaction" log level set to TRACE): - ~40% of test runs produced issue 3 ("2 remove() invocations returned the old value for key 'k4'") - occurred rarely: issue 2 ("remove() did actually remove the key 'k4', but the return value was null) - didn't occur with "org.infinispan.transaction" log level set to TRACE; but otherwise quite often: issue 1 ("remove() of key 'k4' did not succeed, but we got no exception (entry still there; value: 'v')") > Cache#remove(key) not behaving correctly under high load - while primary owner node is stopped > ---------------------------------------------------------------------------------------------- > > Key: ISPN-5307 > URL: https://issues.jboss.org/browse/ISPN-5307 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.1.Final > Reporter: Carsten Lohmann > Attachments: RemoveEntryWhilePrimaryOwnerStopsTest.java, RemoveEntryWhileSingleOwnerStopsTest_2RemoveOpsReturnedNonNullValue.log, RemoveEntryWhileSingleOwnerStopsTest_RemoveFailButNoException.log, RemoveEntryWhileSingleOwnerStopsTest_RemoveOkButReturnedNull.log > > > In our application we had the problem that under high load a {{Cache#remove(key)}} invocation returned the old value _although_ the same key was already removed on another node a few milliseconds before. > This occurred while another node was shutdown - that node happened to be the coordinator and also the primary owner of the key here. > The cache is a distributed, DB-persisted, transactional (locking mode Pessimistic) cache with numOwners=1. > > I could reproduce such an issue with the attached unit test (tested on ISPN 7.1). > Scenario: > - MultipleCacheManagersTest with 3 nodes > - Cache is distributed, persisted, transactional (locking mode Pessimistic) with numOwners 1 or 2 (see below; {{getTestCacheNumOwners()}} in the test) > - a number of test keys get inserted; only keys with the coordinator as primary owner get used for the test > - while the keys get removed one-by-one and concurrently by 2 threads... > - ... the coordinator node gets stopped > > At the end, the return values of the {{remove()}} invocations get checked. > {{remove()}} invocations that threw an error (SuspectException) are ignored. > > *The following problems occurred on some test runs*: > # the {{remove(key)}} invocations on both nodes returned {{null}} and the entry was still there in the end > #* => I would have expected an exception here as {{remove(key)}} essentially failed > # the {{remove(key)}} invocations on both nodes returned {{null}} but the entry was actually removed > #* => wrong return value of first invocation > # the {{remove(key)}} invocations on both nodes returned both the old value > #* => wrong return value of second invocation > > These issues occur not always but quite often with the test. > When testing with {{numOwners=2}}, I only got the last of the above issues - in the test with {{numOwners=1}} that occurred only rarely. > Attached are log files from tests with {{numOwners=1}} > ("org.infinispan.transaction" log level set to TRACE): > - ~40% of test runs produced: > issue 3 ("2 remove() invocations returned the old value for key 'k4'") > - occurred rarely: > issue 2 ("remove() did actually remove the key 'k4', but the return value was null") > - didn't occur with "org.infinispan.transaction" log level set to TRACE; but otherwise quite often: > issue 1 ("remove() of key 'k4' did not succeed, but we got no exception (entry still there; value: 'v')") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5072) MapExternalizer no longer needs to extend InstanceReusingAdvancedExternalizer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5072?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5072: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1200514|https://bugzilla.redhat.com/show_bug.cgi?id=1200514] from POST to MODIFIED > MapExternalizer no longer needs to extend InstanceReusingAdvancedExternalizer > ----------------------------------------------------------------------------- > > Key: ISPN-5072 > URL: https://issues.jboss.org/browse/ISPN-5072 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.1.0.Alpha1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > The MapExternalizer originally extended InstanceReusingAdvancedExternalizer to allow for the CacheStatusResponse class to properly reuse values. However with ISPN-3561 we no longer use just a Map but also a ManagerStatusResponse so we only need the Externalizer for that class to extend InstanceReusingAdvancedExternalizer. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5287) Inconsistent logging for starting and finished rebalance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5287?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5287: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1200947|https://bugzilla.redhat.com/show_bug.cgi?id=1200947] from POST to MODIFIED > Inconsistent logging for starting and finished rebalance > -------------------------------------------------------- > > Key: ISPN-5287 > URL: https://issues.jboss.org/browse/ISPN-5287 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.2.0.Beta1, 7.2.0.Final > > > The node-level rebalance completed events are logged at INFO level, but the cluster-wide rebalance completed event is logged only at DEBUG level, which is not visible by default. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5307) Cache#remove(key) not behaving correctly under high load - while primary owner node is stopped

by Carsten Lohmann (JIRA)

[ https://issues.jboss.org/browse/ISPN-5307?page=com.atlassian.jira.plugin.... ] Carsten Lohmann updated ISPN-5307: ---------------------------------- Attachment: RemoveEntryWhilePrimaryOwnerStopsTest.java RemoveEntryWhileSingleOwnerStopsTest_2RemoveOpsReturnedNonNullValue.log RemoveEntryWhileSingleOwnerStopsTest_RemoveFailButNoException.log RemoveEntryWhileSingleOwnerStopsTest_RemoveOkButReturnedNull.log > Cache#remove(key) not behaving correctly under high load - while primary owner node is stopped > ---------------------------------------------------------------------------------------------- > > Key: ISPN-5307 > URL: https://issues.jboss.org/browse/ISPN-5307 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.1.Final > Reporter: Carsten Lohmann > Attachments: RemoveEntryWhilePrimaryOwnerStopsTest.java, RemoveEntryWhileSingleOwnerStopsTest_2RemoveOpsReturnedNonNullValue.log, RemoveEntryWhileSingleOwnerStopsTest_RemoveFailButNoException.log, RemoveEntryWhileSingleOwnerStopsTest_RemoveOkButReturnedNull.log > > > In our application we had the problem that under high load a {{Cache#remove(key)}} invocation returned the old value _although_ the same key was already removed on another node a few milliseconds before. > This occurred while another node was shutdown - that node happened to be the coordinator and also the primary owner of the key here. > The cache is a distributed, DB-persisted, transactional (locking mode Pessimistic) cache with numOwners=1. > > I could reproduce such an issue with the attached unit test (tested on ISPN 7.1). > Scenario: > - MultipleCacheManagersTest with 3 nodes > - Cache is distributed, persisted, transactional (locking mode Pessimistic) with numOwners 1 or 2 (see below; {{getTestCacheNumOwners()}} in the test) > - a number of test keys get inserted; only keys with the coordinator as primary owner get used for the test > - while the keys get removed one-by-one and concurrently by 2 threads... > - ... the coordinator node gets stopped > > At the end, the return values of the {{remove()}} invocations get checked. > {{remove()}} invocations that threw an error (SuspectException) are ignored. > > *The following problems occurred on some test runs*: > # the {{remove(key)}} invocations on both nodes returned {{null}} and the entry was still there in the end > #* => I would have expected an exception here as {{remove(key)}} essentially failed > # the {{remove(key)}} invocations on both nodes returned {{null}} but the entry was actually removed > #* => wrong return value of first invocation > # the {{remove(key)}} invocations on both nodes returned both the old value > #* => wrong return value of second invocation > > These issues occur not always but quite often with the test. > When testing with {{numOwners=2}}, I only got the last of the above issues - in the test with {{numOwners=1}} that occurred only rarely. > Attached are log files from tests with {{numOwners=1}} > ("org.infinispan.transaction" log level set to TRACE): > - ~40% of test runs produced issue 3 ("2 remove() invocations returned the old value for key 'k4'") > - occurred rarely: issue 2 ("remove() did actually remove the key 'k4', but the return value was null) > - didn't occur with "org.infinispan.transaction" log level set to TRACE; but otherwise quite often: issue 1 ("remove() of key 'k4' did not succeed, but we got no exception (entry still there; value: 'v')") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-2053) Memcached server occasionally does not consume CR/LF after data block

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2053?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2053: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 801296|https://bugzilla.redhat.com/show_bug.cgi?id=801296] from VERIFIED to ASSIGNED > Memcached server occasionally does not consume CR/LF after data block > --------------------------------------------------------------------- > > Key: ISPN-2053 > URL: https://issues.jboss.org/browse/ISPN-2053 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 5.1.5.CR1 > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 5.1.5.FINAL > > > The memcached server sometimes "forgets" to read the ending CR/LF after value payloads. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5307) Cache#remove(key) not behaving correctly under high load - while primary owner node is stopped

by Carsten Lohmann (JIRA)

Carsten Lohmann created ISPN-5307: ------------------------------------- Summary: Cache#remove(key) not behaving correctly under high load - while primary owner node is stopped Key: ISPN-5307 URL: https://issues.jboss.org/browse/ISPN-5307 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.1.1.Final Reporter: Carsten Lohmann In our application we had the problem that under high load a {{Cache#remove(key)}} invocation returned the old value _although_ the same key was already removed on another node a few milliseconds before. This occurred while another node was shutdown - that node happened to be the coordinator and also the primary owner of the key here. The cache is a distributed, DB-persisted, transactional (locking mode Pessimistic) cache with numOwners=1. I could reproduce such an issue with the attached unit test (tested on ISPN 7.1). Scenario: - MultipleCacheManagersTest with 3 nodes - Cache is distributed, persisted, transactional (locking mode Pessimistic) with numOwners 1 or 2 (see below; {{getTestCacheNumOwners()}} in the test) - a number of test keys get inserted; only keys with the coordinator as primary owner get used for the test - while the keys get removed one-by-one and concurrently by 2 threads... - ... the coordinator node gets stopped At the end, the return values of the {{remove()}} invocations get checked. {{remove()}} invocations that threw an error (SuspectException) are ignored. *The following problems occurred on some test runs*: # the {{remove(key)}} invocations on both nodes returned {{null}} and the entry was still there in the end #* => I would have expected an exception here as {{remove(key)}} essentially failed # the {{remove(key)}} invocations on both nodes returned {{null}} but the entry was actually removed #* => wrong return value of first invocation # the {{remove(key)}} invocations on both nodes returned both the old value #* => wrong return value of second invocation These issues occur not always but quite often with the test. When testing with {{numOwners=2}}, I only got the last of the above issues - in the test with {{numOwners=1}} that occurred only rarely. Attached are log files from tests with {{numOwners=1}} ("org.infinispan.transaction" log level set to TRACE): - ~40% of test runs produced issue 3 ("2 remove() invocations returned the old value for key 'k4'") - occurred rarely: issue 2 ("remove() did actually remove the key 'k4', but the return value was null) - didn't occur with "org.infinispan.transaction" log level set to TRACE; but otherwise quite often: issue 1 ("remove() of key 'k4' did not succeed, but we got no exception (entry still there; value: 'v')") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5300) CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5300?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5300: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1202413|https://bugzilla.redhat.com/show_bug.cgi?id=1202413] from POST to MODIFIED > CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5300 > URL: https://issues.jboss.org/browse/ISPN-5300 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Beta1, 7.2.0.Final, 7.1.2.Final > > > Current implementetion passes the value as old value to the wrapped filter. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2015