[
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)
