[ https://issues.apache.org/jira/browse/FLINK-18429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephan Ewen resolved FLINK-18429. ---------------------------------- Resolution: Fixed Fixed in - 1.11.0 via a60a4a9c71a2648176ca46a25230920674130d01 - 1.12.0 (master) via 4776813cc335080dbe8684f51c3aa0f7f1d774d0 > 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)