[
https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin....
]
Karim AMMOUS commented on JGRP-1876:
------------------------------------
I reproduced the problem and got the attached log files. Here is the scenario:
{noformat}
- View: [A, B, C]
View: [A-192.168.10.3|2] (3) [A-192.168.10.3, B-192.168.10.3, C-192.168.10.3]
- Isolate C
INFO janv. 18 17:45:40,218 | AWT-EventQueue-0 | (protocols.DISCARD) | Setting discard all
value to: true
- Views:
View: [A-192.168.10.3|3] (2) [A-192.168.10.3, B-192.168.10.3]
View: [C-192.168.10.3|3] (1) [C-192.168.10.3]
TRACE janv. 18 17:46:55,703 | Timer-2,TEST,A-192.168.10.3 | (protocols.MERGE3) |
A-192.168.10.3: Sending MergeInfo[[A-192.168.10.3|3]]
- No isolate C 2s later
INFO janv. 18 17:46:57,781 | AWT-EventQueue-0 | (protocols.DISCARD) | Setting discard all
value to: false
- C detect incoherent view and proceed to merge
INFO janv. 18 17:47:26,359 | Timer-3,TEST,C-192.168.10.3 | (protocols.MERGE3) |
C-192.168.10.3: found inconsistent views: [C-192.168.10.3|3]: [(1) C-192.168.10.3]
[A-192.168.10.3|3]: [(1) B-192.168.10.3]
- View on B and C : [C-192.168.10.3|4] (2) [C-192.168.10.3, B-192.168.10.3]
{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,
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)