Version 8



    If a group gets split for some reasons (e.g. network partition), this protocol merges the subgroups back into one group. It is only run by the coordinator (the oldest member in a cluster), and periodically multicasts its presence. If another coordinator (for the same group) receives this message, it will initiate a merge process. Note that this merges subgroups {A,B} and {C,D,E} back into {A,B,C,D,E}, but it does not merge state. The app has to handle the  callback to merge state.


    Configuration Example


        <MERGE2 min_interval="5000" max_interval="10000" ></MERGE2>


    Configuration Parameters

    idGive the protocol a different ID if needed so we can have multiple instances of it in the same stack
    inconsistent_view_thresholdNumber of inconsistent  views with only 1 coord after a MERGE event is sent up
    levelSets the logger level (see javadocs)
    max_intervalMaximum time in ms between runs to discover other clusters
    min_intervalMinimum time in msbetween runs to discover other clusters
    nameGive the protocol a different name if needed so we can have multiple instances of it in the same stack
    statsDetermines whether to collect statistics (and expose them via JMX). Default is true


    See also Protocol Configuration Common Parameters.






    If MERGE2 is used in conjunction with TCPPING, the  attribute must contain all the nodes that could potentially be merged back, in order for the merge process to work properly. Otherwise, the merge process would not merge all the nodes even though Shunning is disabled. Alternatively use MPING, which is commonly used with TCP to provide multicast member discovery capabilities, instead of TCPPING to avoid having to specify all the nodes.


    Selection of Coordinator Following Merge


    Following a merge, the coordinator of the merged group can shift from the typical case of "the coordinator is the member who has been up the longest."  During the merge process, the coordinators of the various subgroups need to reach a common decision as to who the new coordinator is.  In order to ensure a consistent result, each coordinator combines the addresses of all the members in a list and then sorts the list.  The first member in the sorted list becomes the coordinator.  The sort order is determined by how the address implements the  interface. The JGroups  compare based on the  and then the port.  So, take a hypothetical case where two machines were running, with one machine running three separate cluster members and the other two members. If communication between the machines were cut, the following subgroups would form:


    {,} and {,,}


    Following the merge, the new view would be:




    with as coordinator.


    Back To JGroups