JGroups Protocol MERGE2: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (26 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=External= | |||
* JGroups Manual http://www.jgroups.org/manual/html/protlist.html#MERGE2 | |||
* JGroups Wiki http://community.jboss.org/wiki/JGroupsMERGE2 | |||
=Internal= | =Internal= | ||
* [[JGroups#Protocols|JGroups]] | * [[JGroups#Protocols|JGroups]] | ||
=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. | |||
|[JGroups] | 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. | ||
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]] | |||
</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 | The result of GET_MBRS_REQ is a list of <tt>PingData</tt>. | ||
<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. | ||
=Also See= | |||
[ | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[JGroups Protocol MERGE3|MERGE3]] | |||
</blockquote> | |||
Latest revision as of 04:20, 5 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 (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:
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.