[jboss-jira] [JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048921#comment-13048921 ] 

Bela Ban edited comment on JGRP-1910 at 3/11/15 9:34 AM:
---------------------------------------------------------

No, I haven't yet had a chance to complete the PlusCal manual.
What do you mean ? If you're C have view {{\[A|5] \[A,B,C\]}} and then get view {{\[B|6\] \[B,C\]}}, on what grounds would you make C reject it ?


was (Author: belaban):
No, I haven't yet had a chance to complete the PlusCal manual.
What do you mean ? If you're C have view {{\[A|5] \[A,B,C\}}} and the get view {{\[B|6\] \[B,C\}}}, on what grounds would you make C reject it ?

> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
>                 Key: JGRP-1910
>                 URL: https://issues.jboss.org/browse/JGRP-1910
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.6.3
>
>         Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)