[jboss-jira] [JBoss JIRA] Updated: (JGRP-986) FLUSH: relax event sequencing for a joining member

Wed Jun 3 05:07:56 EDT 2009

     [ https://jira.jboss.org/jira/browse/JGRP-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-986:
-------------------------------------

    Description: 
There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a switch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This switch was introduced to always enforce a strict order between view, unblock and message M. 

If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

  was:
There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a latch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If a message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This latch was introduced to always enforce a strict order between view, unblock and message M. 

If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

> FLUSH: relax event sequencing for a joining member
> --------------------------------------------------
>
>                 Key: JGRP-986
>                 URL: https://jira.jboss.org/jira/browse/JGRP-986
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.10, 2.8
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>
> There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a switch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This switch was introduced to always enforce a strict order between view, unblock and message M. 
> If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira