ASF GitHub Bot commented on FLINK-4512:
Github user tillrohrmann commented on a diff in the pull request:
@@ -51,9 +57,11 @@
/** States of the different task groups belonging to this checkpoint */
private final Map<JobVertexID, TaskState> taskStates;
- /** Flag to indicate whether the completed checkpoint data should be
deleted when this
- * handle to the checkpoint is disposed */
- private final boolean deleteStateWhenDisposed;
+ /** Properties for this checkpoint. */
+ private final CheckpointProperties props;
+ /** External path if persisted checkpoint; <code>null</code> otherwise.
+ private final String externalPath;
--- End diff --
Could the external path be part of the `CheckpointProperties`? The external
path could be an `Option<String>`. Then we would get around the null field.
> 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