[
https://issues.jboss.org/browse/JGRP-1674?page=com.atlassian.jira.plugin....
]
Dennis Reed commented on JGRP-1674:
-----------------------------------
Proposed fix details:
STOP_FLUSH is sent in two cases:
1. onResume called with a list of participants.
STOP_FLUSH is sent to each individual participant, so no need to verify that the
STOP_FLUSH is valid in this case.
Did not change this use case.
2. onResume called with "null" participants
STOP_FLUSH is multicast, which may be seen by members that were not in the
START_FLUSH.
Added current flushMembers to the STOP_FLUSH message.
up(STOP_FLUSH) modified to block the STOP_FLUSH only if the newly added flushParticipants
list is not null, and flushParticipants does not include this node, and this node did not
sent the STOP_FLUSH.
STOP_FLUSH race condition
-------------------------
Key: JGRP-1674
URL:
https://issues.jboss.org/browse/JGRP-1674
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.21
Reporter: Dennis Reed
Assignee: Bela Ban
Fix For: 3.4
There is a race condition in STOP_FLUSH when a node joins the cluster.
JOINER sends JOIN_REQ to MASTER
MASTER does a flush on the existing members (does NOT include JOINER)
MASTER sends JOIN_RSP
MASTER sends STOP_FLUSH
JOINER receives JOIN_RSP
JOINER fetches state, sends START_FLUSH
JOINER receives STOP_FLUSH from MASTER (does not apply, since JOINER was not part of the
original FLUSH)
onStopFlush never verifies that the current node was part of the FLUSH, and therefore is
valid for the current node.
This STOP_FLUSH corrupts JOINER's FLUSH by resetting all the member variables (and
probably unblocking as well).
--
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