Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-618

FLUSH coordinator transfer reorders block/unblock/view events in applications (TCP stack only)

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 2.6
    • 2.6
    • None

      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.

              vblagoje Vladimir Blagojevic (Inactive)
              vblagoje Vladimir Blagojevic (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: