[
https://jira.jboss.org/jira/browse/JGRP-986?page=com.atlassian.jira.plugi...
]
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