becketqin commented on pull request #13784: URL: https://github.com/apache/flink/pull/13784#issuecomment-716676477
@StephanEwen Thanks for the suggestion. I like the idea of having a `CheckpointListener` interface. That said, regarding the second option, do we still keep `snapshotState()` after adding `onCheckpoint(checkpointId)`? If we have both methods, users may have to break a checkpoint into two different stages. `snapshotState()` only checkpoints states that are not associated with the checkpointId, and `onCheckpoint(checkpointId)` saves the states that are associated with the checkpointId. To avoid breaking the checkpoint into two stages, the enumerator / reader may have `snapshotState(checkpointId)` while also implement `CheckpointListener`. However, in that case it seems the `snapshotState(checkpointId)` would overtake the `onCheckpoint(checkpointId)`. So I wondering if an interface of `Checkpointable` with `snapshotState(checkpointId)` and `onCheckpointComplete(checkpointId)` would be more suitable here? Maybe both `Checkpointable` and `CheckpointListener` can exist at the same time. * `Checkpointable` is implemented by classes that require some state to be explicitly maintained by Flink. * `CheckpointListener` is implemented by classes that need to be aware of checkpoint, but do not need explicit state maintenance. What do you think? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
