flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-5972) Don't allow shrinking merging windows
Date Wed, 22 Mar 2017 17:58:41 GMT

    [ https://issues.apache.org/jira/browse/FLINK-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936803#comment-15936803

ASF GitHub Bot commented on FLINK-5972:

Github user aljoscha commented on the issue:

    Thanks for the thorough review, @tzulitai!
    And shame over my head for all the code duplication 😱 
    I now refactored the contract tests into a base class and addressed all the issues that
you found (hopefully).
    The failing `WindowOperatorTest` tests actually discovered a real problem, I wasn't taking
the allowed lateness into account when calculating if a merged window would be late. I modified
the new tests in in the contract test to verify that we now have the correct behaviour.
    Could you maybe have another look?

> Don't allow shrinking merging windows
> -------------------------------------
>                 Key: FLINK-5972
>                 URL: https://issues.apache.org/jira/browse/FLINK-5972
>             Project: Flink
>          Issue Type: Bug
>          Components: DataStream API
>    Affects Versions: 1.1.0, 1.2.0, 1.3.0
>            Reporter: Aljoscha Krettek
>            Priority: Blocker
>             Fix For: 1.3.0, 1.2.1
> A misbehaving {{MergingWindowAssigner}} can cause a merge that results in a window that
is smaller than the span of all the merged windows. This, in itself is not problematic. It
becomes problematic when the end timestamp of a window that was not late before merging is
now earlier than the watermark (the timestamp is smaller than the watermark).
> There are two choices:
>  - immediately process the window
>  - drop the window
> processing the window will lead to late data downstream.
> The current behaviour is to silently drop the window but that logic has a bug: we only
remove the dropped window from the {{MergingWindowSet}} but we don't properly clean up state
and timers that the window still (possibly) has. We should fix this bug in the process of
resolving this issue.
> We should either just fix the bug and still silently drop windows or add a check and
throw an exception when the end timestamp falls below the watermark.

This message was sent by Atlassian JIRA

View raw message