MERGE3: merging in large clusters
---------------------------------
Key: JGRP-1387
URL:
https://issues.jboss.org/browse/JGRP-1387
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.1
MERGE2 has the issue that concurrent merges are frequent with large clusters. MERGE3 will
change this and works as follows:
- Every node sends a multicast with its address, logical name, physical address and ViewId
every N seconds
- Every node collects this information and - every N * 1.5 seconds - determines (a)
whether we have different ViewIds and (if so) (b) determines the merge leader from the
collected info
- The merge leader then collects the different Views from the merge participants, and
sends a MERGE event up the stack, so that GMS can start the merge
The benefits of MERGE3 are:
- Good for large clusters, geared toward UDP based stacks
- Only 1 merge in the cluster at any time
- The collection of information to see whether a merge is needed is spaced out over a
longer time period (N secs), compared to MERGE2, which uses Discovery.findAllViews(),
which consists of a multicast and N unicasts. This might cause temporary congestion and
packet loss
- On a merge, the members already have the logical-physical address mapping (unlike
MERGE2)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira