[jira] [Created] (FLINK-13205) Checkpoints/savepoints injection has loose ordering properties when a stop-with-savepoint is triggered

[Shang Yuanchun (Jira)]

Alex created FLINK-13205:
----------------------------

             Summary: Checkpoints/savepoints injection has loose ordering properties when a stop-with-savepoint is triggered
                 Key: FLINK-13205
                 URL: https://issues.apache.org/jira/browse/FLINK-13205
             Project: Flink
          Issue Type: Bug
          Components: Runtime / Checkpointing
    Affects Versions: 1.9.0
            Reporter: Alex
            Assignee: Alex


When a stop-with-savepoint is triggered at a source task, the task's dispatcher ({{Task.asyncCallDispatcher}})'s thread pool is extended (from single-threaded, it becomes multi-threaded).

This leads to a race of applying consequent checkpoints/savepoints from dispatcher's queue at the same time and checkpoints/savepoints would be not strictly ordered in the event stream.

As the result, checkpoints/savepoints that injected later than they should, may be "silently subsumed": potentially, they would be ignored and won't be reported to checkpoint coordinator.

*Proposed solution:*

Revert {{Task.asyncCallDispatcher}} behavior to be single-threaded.
For stop-with-savepoint feature, the dispatcher's thread that performs the synchronous savepoint doesn't need to be blocking and {{StreamTask.finishTask()}} invocation can be delegated to {{StreamTask.notifyCheckpointComplete()}}.

*Note:* imo, the issue described here is not critical, but the proposed change should simplify implementation. This ticket can be considered as enhancement.




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)