[jboss-jira] [JBoss JIRA] (JGRP-1901) GMS: view installation by consensus

[Dan Berindei (JIRA)]

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

Dan Berindei commented on JGRP-1901:
------------------------------------

I think Radim is right. If a node already have a view installed, then it shouldn't just ACK a view from a new coordinator.

But I wouldn't add another timeout on each member. Instead I would add some restrictions on the new view:

1. The new view's id is should be greater than the old one's, so the node wouldn't bounce from one coordinator to another when the network is patchy.
2. If the new view is not a merge view, the new coordinator should be a member of the old view. If the old coordinator is a member of the view, it should be the new coordinator as well.
3. A merge view should be accepted only if we replied to the merge request from the merge coordinator. We should track the accepted merge requests and only accept one merge request at a time (old merge requests should eventually time out).

If a node actively nacks a view update, the coordinator should be able to retry installing a view without that particular node, and eventually start a new merge round.

I'm not sure how workable this is, and you may not like the strong connection to the merge protocol. But I think JGroups needs to be a lot more conservative about changing the coordinator.

> GMS: view installation by consensus
> -----------------------------------
>
>                 Key: JGRP-1901
>                 URL: https://issues.jboss.org/browse/JGRP-1901
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.1
>
>
> Investigate whether view installation should optionally be done via 2PC. Example:
> * View is A,B,C,D, splits into A,B and C,D
> * Before AB is installed in A and B, view A,B,C is installed
> ** (C hasn't been suspected yet. This can happen with {{FD}})
> Infinispan's rebalancing algorithm has problems with this, as it tries to assign state to C which however isn't reachable from the A,B side of the network partition. It would be better if A,B,C,D went directly to A,B and C,D
> Investigate whether we should add a property to {{GMS}} which defines whether to use 2PC for view installation (default would be {{false}}). The algorithm would work as follows:
> * Send a {{PREPARE_VIEW(view)}} message
> * When all responses have been received -> send a {{COMMIT_VIEW}} message
> * Else
> ** Inject SUSPECT(C) event for all misisng acks OR
> ** Set a timer to go off in N ms -> when it fires, send the {{COMMIT_VIEW}} msg
> ** If another view is installed before the tmer goes off (e.g. A,B) -> kill the timer



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)