[
https://issues.apache.org/jira/browse/FLINK-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kostas Kloudas updated FLINK-3715:
----------------------------------
Description:
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.
was:
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 {{WindowOperato}}. 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.
> 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)