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

Stefan Richter commented on FLINK-6755:
---------------------------------------

IMO, this somehow leads to the more general question about the future 
directions of checkpoints and savepoints and their distinguising features. It 
this point, on a very general level, I agree that there is a valid use case for 
this request. With a closer look, I think that it also leaves some open 
questions, e.g. how do the manually triggeres checkpoints interact with the 
automatic ones (reset timer?). It also sounds like the target use case would 
like to have a similar function like stop-with-savepoint, a 
stop-with-checkpoint basically. We would also have to solve the question of 
general side effects: if we introduce triggered checkpoints, do the commit side 
effects (like checkpoints) or not (like savepoints, except if used in the 
context of stop).

Thinking a bit about unification of concepts, so far the de-facto differences 
that evolved are i) ownership for delete and ii) what happens to side-effects. 
We can have the discussion and it probably should start by anwering those 
questions for this idea.

> Allow triggering Checkpoints through command line client
> --------------------------------------------------------
>
>                 Key: FLINK-6755
>                 URL: https://issues.apache.org/jira/browse/FLINK-6755
>             Project: Flink
>          Issue Type: New Feature
>          Components: Command Line Client, Runtime / Checkpointing
>    Affects Versions: 1.3.0
>            Reporter: Gyula Fora
>            Assignee: vinoyang
>            Priority: Major
>
> The command line client currently only allows triggering (and canceling with) 
> Savepoints. 
> While this is good if we want to fork or modify the pipelines in a 
> non-checkpoint compatible way, now with incremental checkpoints this becomes 
> wasteful for simple job restarts/pipeline updates. 
> I suggest we add a new command: 
> ./bin/flink checkpoint <jobID> [checkpointDirectory]
> and a new flag -c for the cancel command to indicate we want to trigger a 
> checkpoint:
> ./bin/flink cancel -c [targetDirectory] <jobID>
> Otherwise this can work similar to the current savepoint taking logic, we 
> could probably even piggyback on the current messages by adding boolean flag 
> indicating whether it should be a savepoint or a checkpoint.



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

Reply via email to