[
https://issues.apache.org/jira/browse/BEAM-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15904597#comment-15904597
]
Aljoscha Krettek commented on BEAM-1674:
----------------------------------------
[~kenn] I actually just thought about the same thing this morning, just setting
the GC timer to {{window.maxTimestamp() + 1}}. :-)
I first thought about having them in different timer internals but that
wouldn't work in Flink because we cannot control, as an operator, which timer
id/namespace is processed first. (Timers don't arrive at the operator as a
bundle of fired timers where I can pick an order of processing. Flink calls an
operator callback for each fired timer.)
> Flink user state GC depends on order of timer firing
> ----------------------------------------------------
>
> Key: BEAM-1674
> URL: https://issues.apache.org/jira/browse/BEAM-1674
> Project: Beam
> Issue Type: Bug
> Components: runner-flink
> Affects Versions: 0.5.0
> Reporter: Aljoscha Krettek
> Assignee: Aljoscha Krettek
> Priority: Blocker
> Fix For: 0.6.0
>
>
> The newly added {{ParDoTest.testEventTimeTimerMultipleKeys()}} fails because
> the {{DoFn}} sets a timer for {{window.maxTimestamp()}} which also happens to
> be the GC timer for the user state. The Flink Runner uses timers to schedule
> GC, the user-set timer and the GC timer have a different timer id, so they
> don't clash. However, if the GC timer is being processed before the user
> timer then the user doesn't have a chance to access the state anymore because
> it will already be cleared out by the time the user timer is being processed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
