[
https://issues.apache.org/jira/browse/FLINK-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16579555#comment-16579555
]
Till Rohrmann commented on FLINK-10074:
---------------------------------------
Since {{setFailOnCheckpointingErrors}} is public, we cannot simply change its
signature. What we could do though, is to add another method
{{setNumberTolerableCheckpointFailures(int)}} which is set by default to {{0}}
and is only respected if {{setFailOnCheckpointingErrors}} is set to {{true}}.
So if the the user on calls {{setFailOnCheckpointingErrors(true)}} then he will
get the same old behaviour. Only after calling
{{setNumberTolerableCheckpointFailures(10)}}, it will wait for 10 checkpoint
failures before failing. If {{setNumberTolerableCheckpointFailures}} is set but
{{setFailOnCheckpointingErrors(false)}}, then checkpoint failures won't fail
the job.
[~thw] would you not reset the counter in case of a restart? This would be hard
to do in case of a JobManager failover and lead to different behaviours
depending on the actual fault.
> 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
>
> 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)
