[
https://issues.apache.org/jira/browse/FLINK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565530#comment-15565530
]
ASF GitHub Bot commented on FLINK-4512:
---------------------------------------
Github user tillrohrmann commented on a diff in the pull request:
https://github.com/apache/flink/pull/2608#discussion_r82778103
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/checkpoint/CheckpointCoordinator.java
---
@@ -219,33 +245,9 @@ public CheckpointCoordinator(
* Shuts down the checkpoint coordinator.
*
* <p>After this method has been called, the coordinator does not accept
- * and further messages and cannot trigger any further checkpoints. All
- * checkpoint state is discarded.
- */
- public void shutdown() throws Exception {
- shutdown(true);
- }
-
- /**
- * Suspends the checkpoint coordinator.
- *
- * <p>After this method has been called, the coordinator does not accept
* and further messages and cannot trigger any further checkpoints.
- *
- * <p>The difference to shutdown is that checkpoint state in the store
- * and counter is kept around if possible to recover later.
- */
- public void suspend() throws Exception {
- shutdown(false);
- }
-
- /**
- * Shuts down the checkpoint coordinator.
- *
- * @param shutdownStoreAndCounter Depending on this flag the checkpoint
- * state services are shut down or suspended.
*/
- private void shutdown(boolean shutdownStoreAndCounter) throws Exception
{
+ public void shutdown(JobStatus jobStatus) throws Exception {
--- End diff --
Didn't you tell me that the verb is `shutDown`?
> Add option for persistent checkpoints
> -------------------------------------
>
> Key: FLINK-4512
> URL: https://issues.apache.org/jira/browse/FLINK-4512
> Project: Flink
> Issue Type: Sub-task
> Components: State Backends, Checkpointing
> Reporter: Ufuk Celebi
> Assignee: Ufuk Celebi
>
> Allow periodic checkpoints to be persisted by writing out their meta data.
> This is what we currently do for savepoints, but in the future checkpoints
> and savepoints are likely to diverge with respect to guarantees they give for
> updatability, etc.
> This means that the difference between persistent checkpoints and savepoints
> in the long term will be that persistent checkpoints can only be restored
> with the same job settings (like parallelism, etc.)
> Regular and persisted checkpoints should behave differently with respect to
> disposal in *globally* terminal job states (FINISHED, CANCELLED, FAILED):
> regular checkpoints are cleaned up in all of these cases whereas persistent
> checkpoints only on FINISHED. Maybe with the option to customize behaviour on
> CANCELLED or FAILED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
