[jira] [Comment Edited] (BEAM-11017) Timer with dataflow runner can be set multiple times (dataflow runner)

["Steve Niemitz (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BEAM-11017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531900#comment-17531900 ] 

Steve Niemitz edited comment on BEAM-11017 at 5/4/22 7:06 PM:
--------------------------------------------------------------

I'd bet this is caused by https://issues.apache.org/jira/browse/BEAM-14239.

Processing time timers will default to the element input timestamp for their output timestamp, so setting the timer multiple times will use a new output timestamp each time.

If you explicitly set the output timestamp to something (end of window?) I bet that'll mitigate this bug.


was (Author: steveniemitz):
I'd bet this is caused by https://issues.apache.org/jira/browse/BEAM-14239

> Timer with dataflow runner can be set multiple times (dataflow runner)
> ----------------------------------------------------------------------
>
>                 Key: BEAM-11017
>                 URL: https://issues.apache.org/jira/browse/BEAM-11017
>             Project: Beam
>          Issue Type: Bug
>          Components: runner-dataflow
>    Affects Versions: 2.22.0, 2.23.0, 2.24.0
>            Reporter: Jan Riede
>            Priority: P1
>
> After the update from version 2.21.0 a timer (processing-time) was not overwritten but additionally set.
> I set a timer several times e.g.:
> processingTimerFamily.get("timer1").offset(Duration.standardSeconds(60)).setRelative();
> for each incoming data in an unbound streaming pipeline.
> According to the documentation the timer should be set back in each case. Since the update it seems that the existing timer is not overwritten but an additional timer (with the same timer-id) is added.
> With directrunner it still works as before.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)