JGroups Protocol MERGE2: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 34: Line 34:
</blockquote>
</blockquote>


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>:


<pre>
<pre>
Line 58: Line 58:
   
   


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.
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.

Revision as of 06:39, 3 March 2016

External

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:

GET_MBRS_REQ requests handling by the Discovery protocols

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:

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])



usually by sending a GET_MBRS_REQ message. More about this process here PING GET_MBRS_REQ Requests.






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