[
https://issues.apache.org/jira/browse/BEAM-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16274684#comment-16274684
]
Kenneth Knowles commented on BEAM-170:
--------------------------------------
I think there are some new thoughts on this. For a long time, we've wanted to
stop triggers from "finishing" and closing the window. With that change
implemented, two sessions with the same key and bounds cannot both exist - they
will merge. So that part is solved in a simpler way.
The only other way that we would be comparing two sessions by their bounds
(their encoded form) would be if we were doing another GBK on already-merged
sessions, but today that will cause a pipeline to be rejected since you can't
GBK after merging without re-windowing. I don't know if there is a use case
that would convince us to change this, but we haven't seen it yet.
> Session windows should not be identified by their bounds
> --------------------------------------------------------
>
> Key: BEAM-170
> URL: https://issues.apache.org/jira/browse/BEAM-170
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-core
> Reporter: Kenneth Knowles
> Labels: backward-incompatible
>
> Today, if two session windows for the same key have the same bounds, they are
> considered the same window. This is an accident. It is not intended that any
> session windows are considered equal except via the operation of merging them
> into the same session.
> A risk associated with this behavior is that two windows that happen to
> coincide will share per-window-and-key state rather than evolving separately
> and having their separate state reconciled by state merging logic. These code
> paths are not required to be coherent, and in practice they are not.
> In particular, if the trigger for a session window ever finishes, then
> subsequent data in a window with the same bounds will be dropped, whereas if
> it had differed by a millisecond it would have created a new session,
> ignoring the previously closed session.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
