[
https://issues.apache.org/jira/browse/BEAM-12276?focusedWorklogId=601324&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-601324
]
ASF GitHub Bot logged work on BEAM-12276:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 24/May/21 18:34
Start Date: 24/May/21 18:34
Worklog Time Spent: 10m
Work Description: kennknowles commented on pull request #14718:
URL: https://github.com/apache/beam/pull/14718#issuecomment-847247195
To be clear, I do not think that a "hold" is part of the user conceptual
model and I do not think it should be added. It can be up to each runner how it
wants to manage it. The purpose of the method is actually to control the event
timestamp of outputs, and watermarks should be managed by the runner. But, yes,
in practice they all use shared hold code.
I would say this:
1. setting timer with the scope of window => `timer.set(X)` callback
produces outputs with timestamp `X` as a default.
2. setting timer out of the scope of window (within lateness) => user needs
to specify output timestamp since the default does not make sense.
The runner, or runners-core can decide based on many things. For example in
GBK the runners-core actually uses the current watermark value to decide how to
set the hold. If the time of the hold has already passed, then we do some
things to avoid pausing the watermark, just making sure the window does not
expire.
--
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: 601324)
Time Spent: 5h 40m (was: 5.5h)
> 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 40m
> 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)
