[
https://issues.apache.org/jira/browse/FLINK-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537077#comment-16537077
]
ASF GitHub Bot commented on FLINK-9687:
---------------------------------------
Github user aljoscha commented on the issue:
https://github.com/apache/flink/pull/6224
No, the motivation was different but the effect of the change is the same,
I think.
With this change, you can get into a situation where
`Trigger.onEventTime()` returns `FIRE` and there is actually no window contents
to fire. I think this can potentially be confusing for users that write custom
triggers.
I'm not saying that this behaviour is bad, I'm only saying that it changes
the behaviour, and this can be tricky. This was also the main reason why we
didn't change it back when I did the PR. If I remember correctly.
What are the cases where this change leads to an improvement? I think it
rarely happens that a timer fires while a window is empty, so I think we read
the window state in almost all cases when a timer fires.
> Delay the state fetch only when the triggerResult is fire
> ---------------------------------------------------------
>
> Key: FLINK-9687
> URL: https://issues.apache.org/jira/browse/FLINK-9687
> Project: Flink
> Issue Type: Improvement
> Components: Streaming
> Affects Versions: 1.5.0
> Reporter: aitozi
> Assignee: aitozi
> Priority: Major
> Labels: pull-request-available
>
> When the window operator is fired by the event timer or processing timer, it
> fetch the state content first. I think it only need to fetch the content from
> windowState when the triggerResult is Fire. So we have to change the order to
> avoid this cost ( the cost of fetch content from state is more than judge the
> triggerResult).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
