[jboss-jira] [JBoss JIRA] (JGRP-1484) SEQUENCER and merge-views broken

[David Hotham (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715526#comment-12715526 ] 

David Hotham edited comment on JGRP-1484 at 9/4/12 3:26 AM:
------------------------------------------------------------

I must say, I prefer my fix!

It took me a while to figure out how my proposal could lead to messages and views being mis-ordered.  I think it requires:

* a merge participant P
* whose coordinator C agrees that he is a coordinator
** (for else its SEQUENCER wouldn't broadcast C's messages at all)
* but C fails to announce itself as a coordinator during the merge
** (for else P would not have been a participant)

Then messages broadcast from P may be mis-ordered with respect to the MergeView.

Do you agree that those are the required circumstances and problematic messages, or do you think the problem is more general than that?

In contrast, if you mark the merge view multicast as NO_TOTAL_ORDER then everyone's messages are allowed to be mis-ordered with respect to the MergeView, even in perfectly normal circumstances (ie even when there's no is-C-a-coordinator-or-not? issue).

>From an application point of view I'd _much_ prefer that MergeViews and messages are nearly always correctly ordered, than give up altogether.
                
      was (Author: dimbleby):
    I must say, I prefer my fix!

It took me a while to figure out how my proposal could lead to messages and views being mis-ordered.  I think it requires:

* a merge participant P
* whose coordinator C agrees that he is a coordinator
** (for else its SEQUENCER wouldn't broadcast C's messages at all)
* but who fails to announce itself as a coordinator during the merge
** (for else P would not have been a participant)

Then messages broadcast from P may be mis-ordered with respect to the MergeView.

Do you agree that those are the required circumstances and problematic messages, or do you think the problem is more general than that?

In contrast, if you mark the merge view multicast as NO_TOTAL_ORDER then everyone's messages are allowed to be mis-ordered with respect to the MergeView, even in perfectly normal circumstances (ie even when there's no is-C-a-coordinator-or-not? issue).

>From an application point of view I'd _much_ prefer that MergeViews and messages are nearly always correctly ordered, than give up altogether.
                  
> 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