[jira] [Comment Edited] (FLINK-8871) Checkpoint cancellation is not propagated to stop checkpointing threads on the task manager

["vinoyang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844646#comment-16844646 ] 

vinoyang edited comment on FLINK-8871 at 5/21/19 8:58 AM:
----------------------------------------------------------

[~carp84] There are three similar issues here, they all raise similar questions in essence (the other two are: FLINK-10966, FLINK-12058), but considering that they come from different reporters, it is not appropriate to mark them as duplicates now, but I hope these issues are more focused (such as the same assignee, this can avoid potential duplication of work). I'm watching the design of the Task's actor style, and recently we've introduced a {{CheckpointFailureManager}} that might take on some of the logic for failing responsibility management, which of course requires discussion and design. In each of the three issues, I participated in the discussion separately, and during this past period of time, I have focused on the improvement and refactoring of checkpoints. If they all have implementation conditions and I haven't responded to these issues for a long time, feel free to assign them to others.


was (Author: yanghua):
[~carp84] There are three similar issues here, they all raise similar questions in essence (the other two are: FLINK-10996, FLINK-12058), but considering that they come from different reporters, it is not appropriate to mark them as duplicates now, but I hope these issues are more focused (such as the same assignee, this can avoid potential duplication of work). I'm watching the design of the Task's actor style, and recently we've introduced a {{CheckpointFailureManager}} that might take on some of the logic for failing responsibility management, which of course requires discussion and design. In each of the three issues, I participated in the discussion separately, and during this past period of time, I have focused on the improvement and refactoring of checkpoints. If they all have implementation conditions and I haven't responded to these issues for a long time, feel free to assign them to others.

> Checkpoint cancellation is not propagated to stop checkpointing threads on the task manager
> -------------------------------------------------------------------------------------------
>
>                 Key: FLINK-8871
>                 URL: https://issues.apache.org/jira/browse/FLINK-8871
>             Project: Flink
>          Issue Type: Bug
>          Components: Runtime / Checkpointing
>    Affects Versions: 1.3.2, 1.4.1, 1.5.0, 1.6.0, 1.7.0
>            Reporter: Stefan Richter
>            Assignee: vinoyang
>            Priority: Critical
>
> Flink currently lacks any form of feedback mechanism from the job manager / checkpoint coordinator to the tasks when it comes to failing a checkpoint. This means that running snapshots on the tasks are also not stopped even if their owning checkpoint is already cancelled. Two examples for cases where this applies are checkpoint timeouts and local checkpoint failures on a task together with a configuration that does not fail tasks on checkpoint failure. Notice that those running snapshots do no longer account for the maximum number of parallel checkpoints, because their owning checkpoint is considered as cancelled.
> Not stopping the task's snapshot thread can lead to a problematic situation where the next checkpoints already started, while the abandoned checkpoint thread from a previous checkpoint is still lingering around running. This scenario can potentially cascade: many parallel checkpoints will slow down checkpointing and make timeouts even more likely.
>  
> A possible solution is introducing a {{cancelCheckpoint}} method  as counterpart to the {{triggerCheckpoint}} method in the task manager gateway, which is invoked by the checkpoint coordinator as part of cancelling the checkpoint.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)