[
https://issues.apache.org/jira/browse/FLINK-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306455#comment-15306455
]
Aljoscha Krettek commented on FLINK-3715:
-----------------------------------------
Yes, this would be a restriction. I posted a new design doc to the ML thread,
maybe we can also have the discussion there. In the end we might still have to
keep the distinction between FIRE and PURGE.
> Move Accumulating/Discarding from Trigger to WindowOperator
> -----------------------------------------------------------
>
> Key: FLINK-3715
> URL: https://issues.apache.org/jira/browse/FLINK-3715
> Project: Flink
> Issue Type: Sub-task
> Components: Streaming
> Reporter: Aljoscha Krettek
>
> As mentioned in
> https://docs.google.com/document/d/1Xp-YBf87vLTduYSivgqWVEMjYUmkA-hyb4muX3KRl08/edit#heading=h.pyk1sn8f33q2
> we should move the decision of whether to {{PURGE}} a window upon firing
> from the {{Trigger}} to the {{WindowOperator}}. This also requires to add API
> so that the user can specify whether windows should be purged upon trigger
> firing (discarding) or kept (accumulating).
> As mentioned in the above doc, the {{Trigger}} can react with 4 results right
> now: {{CONTINUE}}, {{FIRE}}, {{PURGE}}, {{FIRE_AND_PURGE}}. The behavior of a
> trigger is not apparent if not looking at the code of the trigger, this has
> confused a number of users. With the new regime, a {{Trigger}} can just
> decide whether to {{CONTINUE}} or {{FIRE}}. The setting of
> accumulating/discarding decides whether to purge the window or keep it.
> This depends on FLINK-3714 where we introduce an "allowed lateness" setting.
> Having a choice between accumulating and discarding only makes sense with an
> allowed lateness greater zero. Otherwise no late elements could ever arrive
> that would go into the kept windows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
