You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "juntaozhang (Jira)" <ji...@apache.org> on 2024/10/01 02:59:00 UTC
[jira] [Commented] (FLINK-5601) Window operator does not checkpoint watermarks
[ https://issues.apache.org/jira/browse/FLINK-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886061#comment-17886061 ]
juntaozhang commented on FLINK-5601:
------------------------------------
[~danderson] ,thank you so much for letting me know the background
> Window operator does not checkpoint watermarks
> ----------------------------------------------
>
> Key: FLINK-5601
> URL: https://issues.apache.org/jira/browse/FLINK-5601
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Checkpointing
> Affects Versions: 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0
> Reporter: Ufuk Celebi
> Priority: Not a Priority
> Labels: auto-deprioritized-critical, auto-deprioritized-major, auto-deprioritized-minor, auto-unassigned, pull-request-available
>
> During release testing [~stefanrichter83@gmail.com] and I noticed that watermarks are not checkpointed in the window operator.
> This can lead to non determinism when restoring checkpoints. I was running an adjusted {{SessionWindowITCase}} via Kafka for testing migration and rescaling and ran into failures, because the data generator required determinisitic behaviour.
> What happened was that on restore it could happen that late elements were not dropped, because the watermarks needed to be re-established after restore first.
> [~aljoscha] Do you know whether there is a special reason for explicitly not checkpointing watermarks?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)