FLUSH coordinator transfer reorders block/unblock/view events in applications (TCP stack
only)
----------------------------------------------------------------------------------------------
Key: JGRP-618
URL:
http://jira.jboss.com/jira/browse/JGRP-618
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
When flush coordinator A runs a flush for a view that excludes himself a flush coordinator
transfer occurs. Member B that is first next neighbor of A according to view has to
complete the flush by sending STOP_FLUSH to all.
Simplification of FLUSH JGRP-598 removed complex stop flush phase. In new design as soon
as member receives STOP_FLUSH it unblocks application by sending UNBLOCK. Now, during
coordinator transfer described above we first have to send a view up to application and
then invoke STOP_FLUSH. If we do it other way around STOP_FLUSH will loop back and cause
delivery of UNBLOCK to application prior to new view - thus causing reordering of
block/unblock/view events in applications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira