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

Merge: add second line of defense for killing of runaway merge tasks

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Done
    • Icon: Major Major
    • 3.0
    • None
    • None

      This prevents the following scenario:

      • A merge ID is set and the merge task started
      • If the merge task ends without setting merge-id back to null, subsequent merge requests will be rejected, because the merge coordinator thinks there is a merge still ongoing
      • This should not happen, but I nevertheless want to add a second line of defense to prevent this

      SOLUTION:

      • Whenever a merge-id is assigned and the merge task started, we also keep track of the time this happened
      • A separate timer task is started and runs every (say) M seconds (e.g. 2 minutes)
      • The task checks whether the time stamp of the last merge (if not 0 (= no merge is running)) is more than N seconds old
      • (M and N are configurable)
      • If this is the case, then we force-cancel the merge
      • The forceCancelMerge() operation is also exposed via JMX, so it can be invoked (e.g.) across a cluster: probe.sh op=GMS.forceCancelMerge

              rhn-engineering-bban Bela Ban
              rhn-engineering-bban Bela Ban
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: