[jboss-jira] [JBoss JIRA] (JGRP-1976) Choose the next coordinator from the largest sub-cluster when merge

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1976:
---------------------------
    Comment: was deleted

(was: Question: why do you take the *first* largest partition? Why don't you iterate through all partitions first to determin the largest partition?)


> Choose the next coordinator from the largest sub-cluster when merge
> -------------------------------------------------------------------
>
>                 Key: JGRP-1976
>                 URL: https://issues.jboss.org/browse/JGRP-1976
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Osamu Nagano
>            Assignee: Bela Ban
>             Fix For: 3.6.7
>
>         Attachments: LargestWinningPolicy.java
>
>
> When sub-clusters merge, the current DefaultMembershipPolicy collects all coordinators from the sub-clusters and sorts it, then chooses the first one as the next coordinator (JGRP-1002).  The sort is done by UUID which is random.  Please consider to change the algorithm slightly to choose the one from the largest (in terms of the number of members) sub-cluster and make it the default.
> Choosing the largest one is reasonable from many point of views.  For example, a WildFly cluster hosting a singleton service becomes more robust.  Another scenario is about a large Inifnispan cluster.  When you add an extra node and the node resides into another network segment, the new node tends to become an isolated coordinator initially (because a switch requires some time to reflect a new multicast route between the segments) then merges later.  With the current implementation, this new node becomes the coordinator frequently and affects stability of the cluster by a cluster-wide rebalance.  This is bad because the intention is to ease the cluster, not to unstabilize it.
> The implementation can be customized by membership_change_policy property of pbcast.GMS.  I attach my implementation as LargestWinningPolicy.java as a reference.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)