December 2014 - infinispan-issues

[JBoss JIRA] (ISPN-5027) OutOfMemoryError in entry retriever when state transfer chunk size is Integer.MAX_VALUE

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5027?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5027: ---------------------------------- Fix Version/s: 7.0.3.Final > OutOfMemoryError in entry retriever when state transfer chunk size is Integer.MAX_VALUE > --------------------------------------------------------------------------------------- > > Key: ISPN-5027 > URL: https://issues.jboss.org/browse/ISPN-5027 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Priority: Optional > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > {{DistributedEntryRetriever}} pre-allocates an {{ArrayDeque}} and and {{ArrayBlockingQueue}} of the same size as the state transfer chunk size. > {{ReplStateTransferCacheLoaderTest}} sets the state transfer chunk size to {{Integer.MAX_VALUE}}, so it will trigger an {{OutOfMemoryError}} at the end of the test, when {{TestingUtil.killCaches()}} tries to log the contents of the cache (if TRACE logging is enabled). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5000) Cleanup rebalance confirmation collector when node is not coord

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5000?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5000: ---------------------------------- Fix Version/s: 7.0.3.Final > Cleanup rebalance confirmation collector when node is not coord > --------------------------------------------------------------- > > Key: ISPN-5000 > URL: https://issues.jboss.org/browse/ISPN-5000 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.1.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > The rebalance confirmation collector is not properly cleared when node becomes non-coordinator. Therefore, when it becomes coordinator, it does not start the rebalance. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3561) A joining cache should receive the rebalancedEnabled flag from the coordinator.

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3561?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3561: ---------------------------------- Fix Version/s: 7.0.3.Final > A joining cache should receive the rebalancedEnabled flag from the coordinator. > ------------------------------------------------------------------------------- > > Key: ISPN-3561 > URL: https://issues.jboss.org/browse/ISPN-3561 > Project: Infinispan > Issue Type: Feature Request > Components: State Transfer > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1 > Reporter: Erik Salter > Assignee: Erik Salter > Fix For: 7.1.0.Beta1, 7.1.0.Final, 7.0.3.Final > > > There is an issue when starting up a set of nodes in a cluster where the coordinator has told the surviving members that state transfer has been disabled. If rebalancing is disabled while the cluster is running it's disabled on all the > However, if a new set of nodes join afterwards, they don't know that rebalancing was disabled. > This has consequences if there is a new coordinator elected (like during a MERGE) from the set of newly-started nodes. > To prevent this and ensure the greatest probablility of success, a node joining should get the state of this flag from the response from the coordinator. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4949: ---------------------------------- Fix Version/s: 7.0.3.Final > Split brain: inconsistent data after merge > ------------------------------------------ > > Key: ISPN-4949 > URL: https://issues.jboss.org/browse/ISPN-4949 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Alpha1, 7.0.3.Final > > > 1) cluster A, B, C, D splits into 2 parts: > A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D] > C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost) > 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D] > 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed > 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime) > 5) The old CH is broadcast in newest topology, no rebalance happens > 6) Inconsistency: read in X may miss the update -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5040) Upgrade to JGroups 3.6.1.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5040?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5040: ---------------------------------- Fix Version/s: 7.0.3.Final > Upgrade to JGroups 3.6.1.Final > ------------------------------ > > Key: ISPN-5040 > URL: https://issues.jboss.org/browse/ISPN-5040 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 7.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > When upgrading, we should remove the DISCARD2 protocol from Infinispan and we should configure NAKACK2 with {{resend_last_seqno=true}}. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5040) Upgrade to JGroups 3.6.1.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5040?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-5040: ------------------------------------- Assignee: Tristan Tarrant (was: Dan Berindei) > Upgrade to JGroups 3.6.1.Final > ------------------------------ > > Key: ISPN-5040 > URL: https://issues.jboss.org/browse/ISPN-5040 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 7.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > When upgrading, we should remove the DISCARD2 protocol from Infinispan and we should configure NAKACK2 with {{resend_last_seqno=true}}. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5040) Upgrade to JGroups 3.6.1.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5040?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5040: ---------------------------------- Status: Open (was: New) > Upgrade to JGroups 3.6.1.Final > ------------------------------ > > Key: ISPN-5040 > URL: https://issues.jboss.org/browse/ISPN-5040 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 7.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > When upgrading, we should remove the DISCARD2 protocol from Infinispan and we should configure NAKACK2 with {{resend_last_seqno=true}}. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5040) Upgrade to JGroups 3.6.1.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5040?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5040: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3173 > Upgrade to JGroups 3.6.1.Final > ------------------------------ > > Key: ISPN-5040 > URL: https://issues.jboss.org/browse/ISPN-5040 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 7.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > When upgrading, we should remove the DISCARD2 protocol from Infinispan and we should configure NAKACK2 with {{resend_last_seqno=true}}. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4908) Clustered cache with unshared store is inconsistent after restarting one node if entries are deleted during restart

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4908?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4908: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1176021|https://bugzilla.redhat.com/show_bug.cgi?id=1176021] from NEW to ASSIGNED > Clustered cache with unshared store is inconsistent after restarting one node if entries are deleted during restart > ------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-4908 > URL: https://issues.jboss.org/browse/ISPN-4908 > Project: Infinispan > Issue Type: Bug > Environment: Clustered REPL cache, preloaded, no eviction/expiration > Reporter: Wolf-Dieter Fink > Assignee: William Burns > > If a cache instance with an unshared cache store is down and the cache is changed until the instance is back and join the cluster the cache can become inconsisstent. > If entries are deleted during downtime, > - the with stale object is loaded first if preload=true > - the local entries are updated with new and changed objects from the cluster > - removed entries from the cluster are not seen and therefore not deleted > After complete sync (only) this instance will have stale objects. > From a consistence and performance perspective the store should be pruned on cluster-join by default in this case -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4908) Clustered cache with unshared store is inconsistent after restarting one node if entries are deleted during restart

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4908?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4908: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1158839, https://bugzilla.redhat.com/show_bug.cgi?id=1176021 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1158839) > Clustered cache with unshared store is inconsistent after restarting one node if entries are deleted during restart > ------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-4908 > URL: https://issues.jboss.org/browse/ISPN-4908 > Project: Infinispan > Issue Type: Bug > Environment: Clustered REPL cache, preloaded, no eviction/expiration > Reporter: Wolf-Dieter Fink > Assignee: William Burns > > If a cache instance with an unshared cache store is down and the cache is changed until the instance is back and join the cluster the cache can become inconsisstent. > If entries are deleted during downtime, > - the with stale object is loaded first if preload=true > - the local entries are updated with new and changed objects from the cluster > - removed entries from the cluster are not seen and therefore not deleted > After complete sync (only) this instance will have stale objects. > From a consistence and performance perspective the store should be pruned on cluster-join by default in this case -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2014