[ https://issues.apache.org/jira/browse/FLINK-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15327400#comment-15327400 ]
ASF GitHub Bot commented on FLINK-3714: --------------------------------------- Github user aljoscha commented on the issue: https://github.com/apache/flink/pull/2093 I had some inline comments. One other thing I would like to see changed is moving the logic that checks whether to do cleanup from `cleanup()` to the call-site. So in `processElement()` it would be: ``` if (combinedTriggerResult.isPurge) { cleanup(...); } else { registerCleanupTimer(...); } ``` The reason for this is that the check in `cleanup()` for whether a timer is a cleanup timer does not take into account the event-time/processing-time split: if a processing-time timer fires on exactly the cleanup time of an event-time window this would also trigger cleanup. The code in `processTriggersFor` (which, by the way can be moved back into `processWatermark()` now that you refactored this special event-time trigger hack) would have this check: ``` if (assigner.isEventTime() && isCleanupTimer(...)) ``` while the code in `trigger()` would be ``` if (!assigner.isEventTime() && isCleanupTimer(...)) ``` > Add Support for "Allowed Lateness" > ---------------------------------- > > Key: FLINK-3714 > URL: https://issues.apache.org/jira/browse/FLINK-3714 > Project: Flink > Issue Type: Sub-task > Components: Streaming > Reporter: Aljoscha Krettek > Assignee: Kostas Kloudas > > As mentioned in > https://docs.google.com/document/d/1Xp-YBf87vLTduYSivgqWVEMjYUmkA-hyb4muX3KRl08/edit# > we should add support for an allowed lateness setting. > This includes several things: > - API for setting allowed lateness > - Dropping of late elements > - Garbage collection of windows state/timers > Depending on whether the {{WindowAssigner}} assigns windows based on event > time or processing time we have to adjust the GC behavior. For event-time > windows "allowed lateness" makes sense and we should garbage collect after > this expires. For processing-time windows "allowed lateness" does not make > sense and we should always GC window state/timers at the end timestamp of a > processing-time window. I think that we need a method for this on > {{WindowAssigner}} that allows to differentiate between event-time windows > and processing-time windows: {{boolean WindowAssigner.isEventTime()}}. -- This message was sent by Atlassian JIRA (v6.3.4#6332)