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

ASF GitHub Bot commented on FLINK-10074:
----------------------------------------

yanghua commented on issue #6567: [FLINK-10074] Allowable number of checkpoint 
failures
URL: https://github.com/apache/flink/pull/6567#issuecomment-423940208
 
 
   @azagrebin thanks for your suggestion, I agree and reconsider more details.
   
   Considering that @tillrohrmann  has said that the current checkpoint 
exception handler should also be implemented in `CheckpointCoordinator`. 
   
   > I understand why you implemented it the way you did. I think the 
`setFailOnCheckpointingErrors` should actually also be handled by the 
`CheckpointCoordinator`/`JM` and not on the Task level (but this is a different 
story). This looks a little bit like a shortcut we made back in the days.
   
   Do we need to take this refactoring into account? Because this PR is 
actually a supplement to the checkpoint exception handler.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Allowable number of checkpoint failures 
> ----------------------------------------
>
>                 Key: FLINK-10074
>                 URL: https://issues.apache.org/jira/browse/FLINK-10074
>             Project: Flink
>          Issue Type: Improvement
>          Components: State Backends, Checkpointing
>            Reporter: Thomas Weise
>            Assignee: vinoyang
>            Priority: Major
>              Labels: pull-request-available
>
> For intermittent checkpoint failures it is desirable to have a mechanism to 
> avoid restarts. If, for example, a transient S3 error prevents checkpoint 
> completion, the next checkpoint may very well succeed. The user may wish to 
> not incur the expense of restart under such scenario and this could be 
> expressed with a failure threshold (number of subsequent checkpoint 
> failures), possibly combined with a list of exceptions to tolerate.
>  



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

Reply via email to