[
https://issues.apache.org/jira/browse/BEAM-14244?focusedWorklogId=752841&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752841
]
ASF GitHub Bot logged work on BEAM-14244:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 05/Apr/22 12:33
Start Date: 05/Apr/22 12:33
Worklog Time Spent: 10m
Work Description: je-ik commented on code in PR #17262:
URL: https://github.com/apache/beam/pull/17262#discussion_r842730013
##########
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:
OK, I somehow managed overlook this. :)
Two notes:
a) yes, for instance FlinkRunner definitely holds watermarks only for
event-time timers (this is bad, looks like missing more @ValidatesRunner tests)
and
b) this seems inconsistent with how event-time timers work, which set
output timestamp based on the fire timestamp (by default). Do we have a reason
for such a difference? And what about looping processing-time timers, where
there is actually no element? The default of output being the output watermark
seems logically consistent with the event-time timers, because the output
watermark gives the event-time position.
##########
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:
OK, I somehow managed to overlook this. :)
Two notes:
a) yes, for instance FlinkRunner definitely holds watermarks only for
event-time timers (this is bad, looks like missing more @ValidatesRunner tests)
and
b) this seems inconsistent with how event-time timers work, which set
output timestamp based on the fire timestamp (by default). Do we have a reason
for such a difference? And what about looping processing-time timers, where
there is actually no element? The default of output being the output watermark
seems logically consistent with the event-time timers, because the output
watermark gives the event-time position.
Issue Time Tracking
-------------------
Worklog Id: (was: 752841)
Time Spent: 1h (was: 50m)
> 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: 1h
> 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)
