[
https://issues.apache.org/jira/browse/BEAM-12276?focusedWorklogId=601538&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-601538
]
ASF GitHub Bot logged work on BEAM-12276:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 25/May/21 06:22
Start Date: 25/May/21 06:22
Worklog Time Spent: 10m
Work Description: je-ik commented on pull request #14718:
URL: https://github.com/apache/beam/pull/14718#issuecomment-847575729
The hold part might not be part of conceptual model, but the output
timestamp has direct implications, that involve it. The reason is in the
underlying invariant - if element arrives ahead of watermark, it should stay
ahead of watermark throughout the whole computation, if possible (the same
holds true for droppable data). Therefore, if a timer sets output timestamp for
earlier timestamp than the fire timestamp and the output timestamp is ahead of
output watermark, it simply implies watermark hold, otherwise the element might
be output after the output watermark, causing it to be late (or even droppable).
When it comes to timers that are set for time interval between (endOfWindow,
windowGcTime) the situation is different. There is no way to infer if there
should, or should not be a watermark hold (assuming we enforce the output
timestamp to be within the bounds of window), because the situation is exactly
the same - fire timestamp for windowGc time, output timestamp endOfWindow.
There has to be explicit user-code declarations of this. (e.g.
`timer.withLateOutputTimestamp(...)`, as opposed to
`timer.withOutputTimestamp`, which would have the semantics
"withOnTimeOutputTimestamp").
Conclusion from my side - if we want to implement c) we need a deeper change
to the timer API, it is definitely not about adding/removing/modifying a few
preconditions, we should solve it in different JIRA. Please stop me, if my
conclusions are wrong, otherwise I'll merge this tomorrow - just to make it
explicit, this PR is the option b) from the options above.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 601538)
Time Spent: 5h 50m (was: 5h 40m)
> Timer.withOutputTimestamp(Instant).offset(Duration).setRelative() might fail
> unexpectedly
> -----------------------------------------------------------------------------------------
>
> Key: BEAM-12276
> URL: https://issues.apache.org/jira/browse/BEAM-12276
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-core
> Affects Versions: 2.30.0
> Reporter: Jan Lukavský
> Assignee: Jan Lukavský
> Priority: P2
> Fix For: 2.31.0
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> We check that timer's output timestamp is not before timer fire timestamp.
> The fire timestamp is unknown to user when setting a relative timer and
> therefore cannot be checked in user code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
