JGroups Protocol MERGE3: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=External= | |||
* JGroups Documentation http://www.jgroups.org/manual-3.x/html/protlist.html#MERGE3 | |||
* http://www.jgroups.org/javadoc/org/jgroups/protocols/MERGE3.html | |||
* https://issues.jboss.org/browse/JGRP-1387 | |||
=Internal= | =Internal= | ||
* [[JGroups#Protocols|JGroups]] | * [[JGroups#Protocols|JGroups]] | ||
=Relevance= | |||
* JGroups 3.4.3 (in this version MERGE3 is broken, does not handle "re-incarnation" well) | |||
=Overview= | |||
Protocol to discover subgroups existing due to a network partition that healed. | Protocol to discover subgroups existing due to a network partition that healed. | ||
| Line 23: | Line 19: | ||
Every member periodically broadcasts its address (UUID), logical name, physical address and ViewID information. Other members collect this information and see if the ViewIDs are different (indication of different subpartitions). If they are, the member with the lowest address (first in the sorted list of collected addresses) sends a MERGE event up the stack, which will be handled by GMS. The others do nothing. | Every member periodically broadcasts its address (UUID), logical name, physical address and ViewID information. Other members collect this information and see if the ViewIDs are different (indication of different subpartitions). If they are, the member with the lowest address (first in the sorted list of collected addresses) sends a MERGE event up the stack, which will be handled by GMS. The others do nothing. | ||
The advantage compared to MERGE2 is that there are no merge collisions caused by multiple merges going on. Also, the INFO traffic is spread out over max_interval, and every member sends its physical address with INFO, so we don't need to fetch the physical address first. | The advantage compared to [[JGroups Protocol MERGE2|MERGE2]] is that there are no merge collisions caused by multiple merges going on. Also, the INFO traffic is spread out over max_interval, and every member sends its physical address with INFO, so we don't need to fetch the physical address first. | ||
MERGE3 works over both UDP and TCP transports. | |||
=Benefits over MERGE2= | |||
* Good for large clusters, geared toward UDP based stacks | * Good for large clusters, geared toward UDP based stacks | ||
* Only 1 merge in the cluster at any time | * Only 1 merge in the cluster at any time | ||
=Configuration= | |||
==min_interval== | |||
In milliseconds. Default: 1000. | In milliseconds. Default: 1000. | ||
==max_interval== | |||
In milliseconds. Default: 10000. | In milliseconds. Default: 10000. | ||
=Also See= | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
[ | :[[JGroups Protocol MERGE2|MERGE2]] | ||
</blockquote> | |||
Latest revision as of 09:28, 5 March 2016
External
- JGroups Documentation http://www.jgroups.org/manual-3.x/html/protlist.html#MERGE3
- http://www.jgroups.org/javadoc/org/jgroups/protocols/MERGE3.html
- https://issues.jboss.org/browse/JGRP-1387
Internal
Relevance
- JGroups 3.4.3 (in this version MERGE3 is broken, does not handle "re-incarnation" well)
Overview
Protocol to discover subgroups existing due to a network partition that healed.
Every member periodically broadcasts its address (UUID), logical name, physical address and ViewID information. Other members collect this information and see if the ViewIDs are different (indication of different subpartitions). If they are, the member with the lowest address (first in the sorted list of collected addresses) sends a MERGE event up the stack, which will be handled by GMS. The others do nothing.
The advantage compared to MERGE2 is that there are no merge collisions caused by multiple merges going on. Also, the INFO traffic is spread out over max_interval, and every member sends its physical address with INFO, so we don't need to fetch the physical address first.
MERGE3 works over both UDP and TCP transports.
Benefits over MERGE2
- Good for large clusters, geared toward UDP based stacks
- Only 1 merge in the cluster at any time
Configuration
min_interval
In milliseconds. Default: 1000.
max_interval
In milliseconds. Default: 10000.