JGroups Protocol MERGE2: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 13: Line 13:


==Merging Process==
==Merging Process==
If a group splits, MERGE2 detects the split and re-joins the group.
Split situations:
* A member is inactive (long GC), it is excluded from group, then comes back to life and it's part of an "older" view - the new view multicasted the coordinator does not include it.
* Real network partitions that leads to two subgroups with two coordinators.
The merge protocol is run by coordinator.
On the coordinator, the <tt>FindSubgroupsTask</tt> of the MERGE2 protocol periodically sends a FIND_INITIAL_MBRS down the stack, which is handled by the implementation of the Discovery protocol ([[JGroups Protocol PING|PING]], [[JGroups Protocol MPING|MPING]], [[JGroups Protocol JDBC_PING|JDBC_PING]], etc) usually by sending a GET_MBRS_REQ message. More about this process here [[JGroups Protocol PING#Periodic_GET_MBRS_REQ_Requests|PING GET_MBRS_REQ Requests]].




Line 22: Line 32:


<font color=red>
<font color=red>
If a group gets split for some reason (network partition), this protocol merges the subgroups back into one group. It run only by the coordinator. The <tt>FindSubgroupsTask</tt> of the MERGE2 protocol periodically sends a FIND_INITIAL_MBRS down the stack, which is handled by the implementation of the Discovery protocol ([[JGroups Protocol PING|PING]], [[JGroups Protocol MPING|MPING]], etc) usually by sending a GET_MBRS_REQ message. More about this process here [[JGroups Protocol PING#Periodic_GET_MBRS_REQ_Requests|PING GET_MBRS_REQ Requests]].


The FIND_INITIAL_MBRS events (and consequently GET_MBRS_REQ messages) are sent at random intervals between 'min_interval' and 'max_interval' milliseconds.
The FIND_INITIAL_MBRS events (and consequently GET_MBRS_REQ messages) are sent at random intervals between 'min_interval' and 'max_interval' milliseconds.

Revision as of 06:00, 3 March 2016

External

Internal

Overview

MERGE2 merges split groups.

Merging Process

If a group splits, MERGE2 detects the split and re-joins the group.

Split situations:

  • A member is inactive (long GC), it is excluded from group, then comes back to life and it's part of an "older" view - the new view multicasted the coordinator does not include it.
  • Real network partitions that leads to two subgroups with two coordinators.

The merge protocol is run by coordinator.

On the coordinator, the FindSubgroupsTask of the MERGE2 protocol periodically sends a FIND_INITIAL_MBRS down the stack, which is handled by the implementation of the Discovery protocol (PING, MPING, JDBC_PING, etc) usually by sending a GET_MBRS_REQ message. More about this process here PING GET_MBRS_REQ Requests.






The FIND_INITIAL_MBRS events (and consequently GET_MBRS_REQ messages) are sent at random intervals between 'min_interval' and 'max_interval' milliseconds.

If another coordinator for the same group receives this message, it will initiate a merge process. The merge process does not merge state. The app has to handle the callback to merge state.

Configuration

  <MERGE2 max_interval="100000" min_interval="20000"/>

min_interval

max_interval

If 'max_interval' is smaller or equal with 'min_interval', we get a configuration error:

21:14:16,436 ERROR [MERGE2] @main max_interval has to be greater than min_interval

and the stack won't start.

Also See

MERGE3