[
https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin....
]
Neal Dillman commented on JGRP-2092:
------------------------------------
This scenario happened several times in our lab. We no longer see the issue as it was
worked around with staggering responses for all of the "bulk response" messages
(ie: view change, etc). However, I believe that this could happen again with a marge
enough network and low enough bandwidth. In other words my ounce of prevention is working
out, be the pound of cure would still be the best solution. I had created a unit test as
well and hound the same results. We also ran into partial scenarios where the consistency
checker was being run by one functioning coordinator, but other, non-functioning
coordinators would not respond to the merge and/or the coordinator running the checker did
not think it should be merge leader. In all cases the issue is complicated by the fact
that none of the non-coordinators will trust a new coordinator that is not a member of
their group.
I believe that a solution will involve the 2nd rank host (and maybe the 3rd?) running a
checker to see if the coordinator's viewInfo shows the coordinator as thinking it is,
in fact, a coordinator.
MERGE3: merge never happens
---------------------------
Key: JGRP-2092
URL:
https://issues.jboss.org/browse/JGRP-2092
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.11, 4.0
Attachments: jgroups.txt
(Reported by Neal Dillman)
In the case below, a merge doesn't seem to happen. Write a unit test to reprodue
this.
{noformat}
Host A view: B, X, Y, Z, A (where B should be coordinator)
Host B view: C, Q, R, S, B (where C should be coordinator)
Host C view: A, M, N, O, C (where A should be coordinator)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)