You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Zili Chen (Jira)" <ji...@apache.org> on 2020/03/21 13:40:00 UTC

[jira] [Commented] (FLINK-16705) LocalExecutor tears down MiniCluster before client can retrieve JobResult

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

Zili Chen commented on FLINK-16705:
-----------------------------------

It seems the problem is that we want to support {{executeAsync}} while keep {{JobClient}} "stateless" so that we don't have to manage resource. Thus, we add a terminate future in {{LocalExecutor}} to terminate the cluster when the job finished, which, as described here, possibly race with a separated result request.

My opinion would be still we(and the user) manage {{JobClient}} lifecycle so that we ensure the result delivered in {{execute}} (blocking version). Alternative is we make something like {{MiniDispatcher}} to special handle it.

What do you think? cc [~kkl0u] [~aljoscha].

> LocalExecutor tears down MiniCluster before client can retrieve JobResult
> -------------------------------------------------------------------------
>
>                 Key: FLINK-16705
>                 URL: https://issues.apache.org/jira/browse/FLINK-16705
>             Project: Flink
>          Issue Type: Bug
>          Components: Client / Job Submission
>            Reporter: Maximilian Michels
>            Assignee: Maximilian Michels
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> There is a race condition in {{LocalExecutor}} between (a) shutting down the cluster when the job has finished and (b) the client which retrieves the result of the job execution.
> This was observed in Beam, running a large test suite with the Flink Runner.
> We should make sure the job result retrieval and the cluster shutdown do not interfere.



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