[ 
https://issues.apache.org/jira/browse/BEAM-9979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luke Cwik updated BEAM-9979:
----------------------------
    Description: 
When the BeamFnDataReadRunner/DataInputOperation is reused there is a short 
period of time when a progress request could happen before the the start 
function is called resetting the read index to -1.

I believe there should be a way to *reset* an operator before it gets added to 
the set of cached bundle processors separate instead of placing clean-up in any 
*start* functions that those operators may rely on preventing exposing details 
of those operators before *start* may have been invoked.

  was:When the BeamFnDataReadRunner/DataInputOperation is reused there is a 
short period of time when a progress request could happen before the the start 
function is called resetting the read index to -1.


> Fix race condition where the read index maybe reported from the last executed 
> bundle
> ------------------------------------------------------------------------------------
>
>                 Key: BEAM-9979
>                 URL: https://issues.apache.org/jira/browse/BEAM-9979
>             Project: Beam
>          Issue Type: Bug
>          Components: sdk-java-harness, sdk-py-harness
>            Reporter: Luke Cwik
>            Priority: Minor
>             Fix For: 2.22.0
>
>
> When the BeamFnDataReadRunner/DataInputOperation is reused there is a short 
> period of time when a progress request could happen before the the start 
> function is called resetting the read index to -1.
> I believe there should be a way to *reset* an operator before it gets added 
> to the set of cached bundle processors separate instead of placing clean-up 
> in any *start* functions that those operators may rely on preventing exposing 
> details of those operators before *start* may have been invoked.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to