Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-1387

MERGE3: merging in large clusters

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Major Major
    • 3.1
    • None
    • None

      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)

              rhn-engineering-bban Bela Ban
              rhn-engineering-bban Bela Ban
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: