[
https://issues.apache.org/jira/browse/FLINK-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15891709#comment-15891709
]
Wei-Che Wei commented on FLINK-4714:
------------------------------------
Hi [~uce]
I saw you implement {{ZooKeeperCompletedCheckpointStore}} in FLINK-2354 and I
found that recover() method in that will remove all other checkpoint instead of
the latest one.
That means recover() method should be ignored or refined in order to support
this feature, am I right?
I have no idea if there is any side-effect after I change that implementation.
As I know, it should be okey to retain all these complete checkpoints, so I am
confused about the comment you wrote for recovery() in
{{ZooKeeperCompletedCheckpointStore}}. Could you please explain that for me?
Looking forward to your feedback. Thank you.
> Set task state to RUNNING after state has been restored
> -------------------------------------------------------
>
> Key: FLINK-4714
> URL: https://issues.apache.org/jira/browse/FLINK-4714
> Project: Flink
> Issue Type: Improvement
> Components: Distributed Coordination, State Backends, Checkpointing
> Affects Versions: 1.2.0
> Reporter: Till Rohrmann
> Assignee: Wei-Che Wei
>
> The task state is set to {{RUNNING}} as soon as the {{Task}} is executed.
> That, however, happens before the state of the {{StreamTask}} invokable has
> been restored. As a result, the {{CheckpointCoordinator}} starts to trigger
> checkpoints even though the {{StreamTask}} is not ready.
> In order to avoid aborting checkpoints and properly start it, we should
> switch the task state to {{RUNNING}} after the state has been restored.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
