[
https://issues.apache.org/jira/browse/FLINK-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kostas Kloudas updated FLINK-13205:
-----------------------------------
Fix Version/s: 1.9.0
> 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
> Priority: Minor
> Fix For: 1.9.0
>
>
> 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)
