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

Amit Sela commented on BEAM-696:
--------------------------------

[[email protected]] shouldn't the SDK take care/enforce this behaviour and not 
let a runner decide this ? It sounds like for merging windows the CombineFns 
should lookup sideInputs only at extractOutput, otherwise I don't see how 
DataflowRunner is deferring, local-combine cannot guarantee the state of the 
merging window (in a specific bundle), correct ?

I think this issue is about the SDK / Runner API and should be resolved by 
either limiting the use of sideInputs with Sessions or enforcing/instructing 
runners to defer looking-up sideInput until extractOutput executes.

Am I missing something here ?  
  

> Side-Inputs non-deterministic with merging main-input windows
> -------------------------------------------------------------
>
>                 Key: BEAM-696
>                 URL: https://issues.apache.org/jira/browse/BEAM-696
>             Project: Beam
>          Issue Type: Bug
>          Components: beam-model
>            Reporter: Ben Chambers
>            Assignee: Pei He
>
> Side-Inputs are non-deterministic for several reasons:
> 1. Because they depend on triggering of the side-input (this is acceptable 
> because triggers are by their nature non-deterministic).
> 2. They depend on the current state of the main-input window in order to 
> lookup the side-input. This means that with merging
> 3. Any runner optimizations that affect when the side-input is looked up may 
> cause problems with either or both of these.
> This issue focuses on #2 -- the non-determinism of side-inputs that execute 
> within a Merging WindowFn.
> Possible solution would be to defer running anything that looks up the 
> side-input until we need to extract an output, and using the main-window at 
> that point. Specifically, if the main-window is a MergingWindowFn, don't 
> execute any kind of pre-combine, instead buffer all the inputs and combine 
> later.
> This could still run into some non-determinism if there are triggers 
> controlling when we extract output.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to