[
https://issues.jboss.org/browse/JGRP-1674?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1674:
--------------------------------
Is this a standalone JGroups application ? Or do they use JBossCache, as they use state
transfer ?
There might be a workaround: instead of calling JChannel.connect() and then
JChannet.getState(), they could call the connect() method which joins the cluster *and*
does a state transfer in one step. This would make the coordinator suppress the STOP_FLUSH
message after the join, and STOP_FLUSH would only be sent after the state transfer.
Is this possible ?
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