[
https://issues.apache.org/jira/browse/BEAM-14244?focusedWorklogId=752812&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752812
]
ASF GitHub Bot logged work on BEAM-14244:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 05/Apr/22 12:08
Start Date: 05/Apr/22 12:08
Worklog Time Spent: 10m
Work Description: steveniemitz commented on code in PR #17262:
URL: https://github.com/apache/beam/pull/17262#discussion_r842706050
##########
runners/flink/src/test/java/org/apache/beam/runners/flink/translation/wrappers/streaming/DoFnOperatorTest.java:
##########
@@ -305,7 +305,10 @@ public void processElement(
eventTimerWithOutputTimestamp
.withOutputTimestamp(timerOutputTimestamp)
.set(timerTimestamp);
-
processingTimer.offset(Duration.millis(timerTimestamp.getMillis())).setRelative();
+ processingTimer
Review Comment:
> processing time timers do not hold output watermark
Possibly not all runners implement it, but certainly on Dataflow processing
time timers hold the watermark at their output timestamp. And again, if the
user doesn't explicitly set the output timestamp, it is defaulted to the
timestamp of the element (or timer) that set it.
https://github.com/apache/beam/commit/a005fd765a762183ca88df90f261f6d4a20cf3e0
is the commit that added support for this.
Issue Time Tracking
-------------------
Worklog Id: (was: 752812)
Time Spent: 50m (was: 40m)
> Processing time timers should use outputTimestamp rather than input watermark
> for their timestamp
> -------------------------------------------------------------------------------------------------
>
> Key: BEAM-14244
> URL: https://issues.apache.org/jira/browse/BEAM-14244
> Project: Beam
> Issue Type: Bug
> Components: runner-core, sdk-java-core
> Reporter: Steve Niemitz
> Assignee: Steve Niemitz
> Priority: P1
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently processing time timers ignore the outputTimestamp and instead use
> the input watermark at the time they fire. This is wrong because the input
> watermark can have advanced arbitrarily far past the actual output timestamp
> when it fires.
> The correct behavior should be to instead use the outputTimestamp the timer
> was configured to fire with.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)