[jboss-jira] [JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
[
https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin....
]
Karim AMMOUS edited comment on JGRP-1876 at 9/5/14 10:30 AM:
-------------------------------------------------------------
Below a concrete example of a strange merge occurred yesterday. It concerns only 8 members
and Log level of class "Merger" was TRACE.
At beginning : {A, B, C, D, E, F} and {G, H}
Then {A, B, C, D} lost E and F => {A, B, C, D} , {A, B, C, D, E, F} and {G, H}
Views are :
View on A, B, C and D: [A|3] (4) {A, B, C, D}
View on E, F: [A|2] (6) {A, B, C, D, E, F}
View on G and H: [G|1] (2) {G, H}
Then a merge has been processed on 4 subgroups:
[A|3] (4) [A, B, C, D]
[A|2] (1) [G]
[A|2] (1) [H]
[G|1] (2) {G, H}
G was the merge leader and the new coord :MergeView::[G|4] (8) [G, A, B, C, D, E, F, H]
Please find enclosed all members logs.
was (Author: ammous):
Below a concrete example of a strange merge occurred yesterday. It concerns only 8 members
and Log level of class "Merger" was TRACE.
At beginning : {A, B, C, D, E, F} and {G, H}
Then {A, B, C, D} lost E and F => {A, B, C, D} , {A, B, C, D, E, F} and {G, H}
Views are :
View on A, B, C and D: [A|3] (4) {A, B, C, D}
View on E, F: [A|2] (6) {A, B, C, D, E, F}
View on G and H: [G|1] (2) {G, H}
Then a merge has been processed on 4 subgroups:
[A|3] (4) [A, B, C, D]
[A|2] (1) [G]
[A|2] (1) [H]
[G|1] (2) {G, H}
G was the merge leader and the new coord :MergeView::[G|4] (8) [G, A, B, C, D, E, F, H]
Please find enclosed all members logs.
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.6
Attachments: 4Subgroups.zip, DkeJgrpAddress.java, MergeViewWith210Subgroups.log
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.1#6329)