[
https://issues.jboss.org/browse/JGRP-1484?page=com.atlassian.jira.plugin....
]
David Hotham edited comment on JGRP-1484 at 9/4/12 7:46 AM:
------------------------------------------------------------
I wonder if we're having terminology confusion. You say "usually, we have only a
few merge coordinators, but many participants". But I think that usually we have
only a few coordinators, and (if all is well) even fewer participants.
To be clear, by participant I mean a member who has reported himself to the merge leader;
but for whom no coordinator claims responsibility. Eg if A, B, C report {A,B}, {A, B},
{A, B, C} then C is a participant because his supposed coordinator A does not have C in
view.
Then I'm proposing that the merge leader sends INSTALL_MERGE_VIEW
* to A, who broadcasts the new view to A and B
* to C, who installs it directly
(whereas today C will attempt to broadcast the new view to A,B,C - which I claim is
pointless).
was (Author: dimbleby):
I wonder if we're having terminology confusion. You say "usually, we have
only a few merge coordinators, but many participants". But I think that usually we
have only a few coordinators, and (if all is well) even fewer participants.
To be clear, by participant I mean a member who has reported himself to the merge leader;
but for whom no coordinator claims responsibility. Eg if A, B, C report {A,B}, {A, B},
{A, B, C} then C is a participant because his supposed coordinator A does not have C in
view.
Then I'm proposing that the merge leader sends INSTALL_MERGE_VIEW
* to A, who broadcasts it to A and B
* to C, who installs it directly
(whereas today C will attempt to broadcast this to A,B,C - which I claim is pointless).
SEQUENCER and merge-views broken
--------------------------------
Key: JGRP-1484
URL:
https://issues.jboss.org/browse/JGRP-1484
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.10
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Here's a new way in which putting SEQUENCER below GMS is broken.
Start with A having view B|4 [B,A], while B, C and D all have view B|7 [B,C,D].
Now we start a merge, in which B is coordinator. B creates the view C|8 [C, D, A, B].
(I've opened a pull request saying that B surely shouldn't issue a view where the
ViewID says that C was the creator. But I think that this is incidental, and not key to
the bug that I'm reporting here).
Now B sends INSTALL_MERGE_VIEW to B (a coordinator) and A (a merge participant, per
Util.determineMergeParticipants).
B gets this first and broadcasts the new view to [B, C, D]. In particular, B is now not
a coordinator.
Then A gets the INSTALL_MERGE_VIEW, and it too tries broadcasting the new view.
SEQUENCER gets involved, and forwards the broadcast to B (as the coordinator in the old
view). B discards this; it's no longer a coordinator.
So the new view is not installed at A. All future broadcasts from A are forwarded to B,
who discards them. The group is fractured, and none of A's broadcasts are delivered.
I'm not sure what the right fix would be. I wonder whether things should be arranged
so that in a merge:
- coordinators behave as today, broadcasting the new view to their own sub-groups
- but mere participants do not do this: they should just have the new view installed on
them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira