[jboss-jira] [JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups

[Karim AMMOUS (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033441#comment-13033441 ] 

Karim AMMOUS commented on JGRP-1876:
------------------------------------

Since C has not received the A's merge info (A is coordinator) although A appears in B's view, C excludes A during the merge process (view handling). It seems to be the issue.
{noformat}
DEBUG janv. 18 17:47:26,359 | ViewHandler,TEST,C-192.168.10.3 | (pbcast.Merger) | C-192.168.10.3: I will be the leader. Starting the merge task for 3 coords: [B-192.168.10.3, A-192.168.10.3, C-192.168.10.3]
DEBUG janv. 18 17:47:26,390 | MergeTask,TEST,C-192.168.10.3 | (pbcast.Merger) | C-192.168.10.3: merge task C-192.168.10.3::1 started with 2 coords
{noformat}

> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
>                 Key: JGRP-1876
>                 URL: https://issues.jboss.org/browse/JGRP-1876
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.2
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.5.1, 3.6, 3.6.2
>
>         Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews: 
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups 
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:  
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)