[
https://issues.apache.org/jira/browse/FLINK-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845510#comment-16845510
]
vinoyang commented on FLINK-8871:
---------------------------------
[~yunta] OK, I am very happy to hear your own thoughts. Yes, I should ask your
thoughts before I proceed, this is my negligence. In essence, the suggestion to
suspend this improvement is not from me, it comes from Stephan, please take a
look at [this
comment|https://issues.apache.org/jira/browse/FLINK-10966?focusedCommentId=16700759&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16700759].
If the order is really important, then you can compare the time when I propose
the same improvement (in November 2018, and you are in March 2019). If there
are no suggestions for suspension, I have already proposed this improved
version of the PR.
In light of Stephan's suggestion, the premise of this improvement is based on
FLINK-12482(I am preparing to participate in it.). In addition, the
CheckpointFailureManager (FLINK-12364) I recently introduced may also change
its design.
You can prepare PR for it as long as you think it makes sense. Of course, I
will also prepare my PR after the relevant prerequisite work is completed. cc
[~carp84]
> 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)
