[jboss-jira] [JBoss JIRA] (JGRP-1484) SEQUENCER and merge-views broken
[
https://issues.jboss.org/browse/JGRP-1484?page=com.atlassian.jira.plugin....
]
David Hotham commented on JGRP-1484:
------------------------------------
I don't understand your second point. My proposal massively _reduces_ the number of
messages that are sent in the circumstances you describe:
* the merge leader will unicast INSTALL_MERGE_VIEW to all participants anyway. Neither of
us has proposed changing that.
* under the current system, every participant will additionally broadcast this view to his
entire sub-group. (This could become an n-squared flood of messages!)
* whereas under my proposal, every participant will just install the view, without sending
further messages.
I agree that it is very hard to guarantee ordering between MergeViews and messages, and
that neither of us has managed to do it. However it seems that my version does a bit
better in this respect, and is therefore slightly preferable.
From a purely practical point of view, my fix also has the advantage
that I've already done lots of testing with it. That shouldn't be decisive (I can
repeat the testing with your fix, it'll just take time) - but it would make my life
easier if we could keep mine...
I'm not sure I've understood what you don't like about my proposal:
- you've ended up making a fix in GMS anyway, so it's not that
- as above, I think that your worry about sending lots of messages is (if anything) the
wrong way round
Sorry to keep bugging you on this one - but could you explain again why you think my fix
is not as good?
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