[
https://issues.apache.org/jira/browse/FLINK-18429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated FLINK-18429:
-----------------------------------
Labels: pull-request-available (was: )
> Add default method for
> CheckpointListener.notifyCheckpointAborted(checkpointId)
> -------------------------------------------------------------------------------
>
> Key: FLINK-18429
> URL: https://issues.apache.org/jira/browse/FLINK-18429
> Project: Flink
> Issue Type: Bug
> Components: API / DataStream
> Reporter: Stephan Ewen
> Assignee: Stephan Ewen
> Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.11.0
>
>
> The {{CheckpointListener}} interface is implemented by many users. Adding a
> new method {{notifyCheckpointAborted(long)}} to the interface without a
> default method breaks many user programs.
> We should turn this method into a default method:
> - Avoid breaking programs
> - It is in practice less relevant for programs to react to checkpoints
> being aborted then to being completed. The reason is that on completion you
> often want to commit side-effects, while on abortion you frequently do not do
> anything, but let the next successful checkpoint commit all changes up to
> then.
> *Original Confusion*
> There was confusion about this originally, going back to a comment by myself
> suggesting this should not be a default method, incorrectly thinking of it as
> an internal interface:
> https://github.com/apache/flink/pull/8693#issuecomment-542834147
> See also clarification email on the mailing list:
> {noformat}
> About the "notifyCheckpointAborted()":
> When I wrote that comment, I was (apparently wrongly) assuming we were
> talking about an internal interface here, because the "abort" signal was
> originally only intended to cancel the async part of state backend
> checkpoints.
> I just realized that this is exposed to users - and I am actually with Thomas
> on this one. The "CheckpointListener" is a very public interface that many
> users implement. The fact that it is tagged "@PublicEvolving" is somehow not
> aligned with reality. So adding the method here will in reality break lots
> and lots of user programs.
> I think also in practice it is much less relevant for user applications to
> react to aborted checkpoints. Since the notifications there can not be relied
> upon (if there is a task failure concurrently) users always have to follow
> the "newer checkpoint subsumes older checkpoint" contract, so the abort
> method is probably rarely relevant.
> This is something we should change, in my opinion.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
