You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@beam.apache.org by "Kenneth Knowles (Jira)" <ji...@apache.org> on 2021/05/15 17:55:00 UTC

[jira] [Updated] (BEAM-9979) Fix race condition where the read index maybe reported from the last executed bundle

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

Kenneth Knowles updated BEAM-9979:
----------------------------------
    Resolution: Fixed
        Status: Resolved  (was: Resolved)

Hello! Due to a bug in our Jira configuration, this issue had status:Resolved but resolution:Unresolved.

I am bulk editing these issues to have resolution:Fixed

If a different resolution is appropriate, please change it. To do this, click the "Resolve" button (you can do this even for closed issues) and set the Resolution field to the right value.

> 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
>    Affects Versions: 2.21.0, 2.22.0, 2.23.0, 2.24.0
>            Reporter: Luke Cwik
>            Assignee: Luke Cwik
>            Priority: P3
>              Labels: Done
>             Fix For: 2.25.0
>
>          Time Spent: 2h
>  Remaining Estimate: 0h
>
> When the BeamFnDataReadRunner 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)