-
Task
-
Resolution: Done
-
Major
-
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
- is related to
-
JGRP-1379 Make merging more scalable / robust
- Resolved