JGroups Protocol MERGE2: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(24 intermediate revisions by the same user not shown)
Line 8: Line 8:
* [[JGroups#Protocols|JGroups]]
* [[JGroups#Protocols|JGroups]]


=Relevance=


* JGroups 3.4.3 (in this version MERGE2 is broken, does not handle "re-incarnation" well)


!!!Internal
=Overview=


|[JGroups]
MERGE2 merges split groups.


!!!Overview
==Merging Process==


If a group gets split for some reason (network partition), this protocol merges the subgroups back into one group.  
If a group splits, MERGE2 detects the split and re-joins the group.


It is only run by 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], etc) usually by sending a GET_MBRS_REQ message. More about this process here [PING#PeriodicGET_MBRS_REQRequests].
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 FIND_INITIAL_MBRS events (and consequently GET_MBRS_REQ messages) are sent at random intervals between 'min_interval' and 'max_interval' milliseconds.
The merge protocol is run by coordinator.


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.
On the coordinator, the <tt>FindSubgroupsTask</tt> of the MERGE2 protocol periodically sends a FIND_ALL_VIEWS 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). Upon receiving a FIND_ALL_VIEWS, the discovery protocol sends a GET_MBRS_REQ message.


!!!Configuration Sample
For more details on GET_MBRS_REQ requests handling by the Discovery protocols, see:


{{{
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[JGroups Protocol PING#Periodic_GET_MBRS_REQ_Requests|GET_MBRS_REQ requests handling by the Discovery protocols]]
    <MERGE2 max_interval="100000" min_interval="20000"/>
</blockquote>
 
}}}


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


!min_interval
The result of GET_MBRS_REQ is a list of <tt>PingData</tt>.


!max_interval
<font color=red>TODO more here</font>.


The merge process does not merge state. The app has to handle the callback to merge state.
=Configuration=
==JGroups==
<pre>
  <MERGE2 max_interval="100000" min_interval="20000"/>
</pre>
==WildFly==
<pre>
<subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="tcp">
  <stack name="tcp">
      ...
    <protocol type="MERGE2"/>
    ...
  </stack>
</subsystem>
</pre>
=Parameters=
==min_interval==
==max_interval==


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


{{{
<pre>
21:14:16,436 ERROR [MERGE2] @main max_interval has to be greater than min_interval
21:14:16,436 ERROR [MERGE2] @main max_interval has to be greater than min_interval
}}}
</pre>


and the stack won't start.
and the stack won't start.


__Referenced by:__\\
=Also See=
[{INSERT com.ecyrd.jspwiki.plugin.ReferringPagesPlugin WHERE max=20, maxwidth=50}]
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[JGroups Protocol MERGE3|MERGE3]]
</blockquote>

Latest revision as of 04:20, 5 March 2016

External

Internal

Relevance

  • JGroups 3.4.3 (in this version MERGE2 is broken, does not handle "re-incarnation" well)

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.

TODO more here.

The merge process does not merge state. The app has to handle the callback to merge state.

Configuration

JGroups

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

WildFly

<subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="tcp">
   <stack name="tcp">
      ...
     <protocol type="MERGE2"/>
     ...
   </stack>
</subsystem>

Parameters

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
Retrieved from "https://kb.novaordis.com/index.php?title=JGroups_Protocol_MERGE2&oldid=4621"