JGroups Protocol MERGE2: Difference between revisions
Line 34: | Line 34: | ||
</blockquote> | </blockquote> | ||
The FIND_ALL_VIEWS events (and consequently GET_MBRS_REQ messages) are sent at random intervals between 'min_interval' and 'max_interval' milliseconds. The result of GET_MBRS_REQ is a list of <tt>PingData</tt> | The FIND_ALL_VIEWS events (and consequently GET_MBRS_REQ messages) are sent at random intervals between 'min_interval' and 'max_interval' milliseconds. | ||
The result of GET_MBRS_REQ is a list of <tt>PingData</tt>. The example below shows a FIND_ALL_VIEWS indicating that '''no''' partition happened. | |||
<pre> | <pre> |
Revision as of 06:49, 3 March 2016
External
- JGroups Manual http://www.jgroups.org/manual/html/protlist.html#MERGE2
- JGroups Wiki http://community.jboss.org/wiki/JGroupsMERGE2
Internal
Relevance
- JGroups 3.4.3
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_ALL_VIEWS down the stack, which is handled by the implementation of the Discovery protocol (PING, MPING, JDBC_PING, etc). Upon receiving a FIND_ALL_VIEWS, the discovery protocol sends a GET_MBRS_REQ message.
For more details on GET_MBRS_REQ requests handling by the Discovery protocols, see:
The FIND_ALL_VIEWS events (and consequently GET_MBRS_REQ messages) are sent at random intervals between 'min_interval' and 'max_interval' milliseconds.
The result of GET_MBRS_REQ is a list of PingData. The example below shows a FIND_ALL_VIEWS indicating that no partition happened.
TRACE org.jgroups.protocols.MERGE2 (Timer-5,shared=tcp) -- Discovery results: [host03/tcp]: view_id= [host01/tcp]: view_id=[host01/tcp|3] ([host01/tcp|3] (2) [host01/tcp, host03/tcp])
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.