[jboss-jira] [JBoss JIRA] (JGRP-1387) MERGE3: merging in large clusters

[Bela Ban (Resolved) (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1387.
----------------------------

    Resolution: Done

    
> 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