[
https://issues.apache.org/jira/browse/FLINK-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17027453#comment-17027453
]
Till Rohrmann commented on FLINK-15790:
---------------------------------------
If the methods are performing an I/O operation (e.g. sending an HTTP request to
the Kubernetes deployment controller and waiting on its response), then these
methods need to be asynchronous. The important thing is that the main thread of
the {{RpcEndpoint}} must never be blocked.
If there is a distinction between cluster and client, then one should maybe
think about separating interfaces into a client and a cluster kube client
interface. Segregating interfaces is usually a good idea.
> Make FlinkKubeClient and its implementations asynchronous
> ---------------------------------------------------------
>
> Key: FLINK-15790
> URL: https://issues.apache.org/jira/browse/FLINK-15790
> Project: Flink
> Issue Type: Sub-task
> Components: Deployment / Kubernetes
> Affects Versions: 1.10.0
> Reporter: Till Rohrmann
> Priority: Critical
> Fix For: 1.11.0, 1.10.1
>
>
> The {{FlinkKubeClient}} interface offers several methods which are
> synchronous (e.g. {{FlinkKubeClient.createTaskManagerPod}},
> {{FlinkKubeClient.stopPod}}, {{FlinkKubeClient.getPodsWithLabels}}, etc). The
> problem is that these methods are directly used by the
> {{KubernetesResourceManager}} which calls them from the main thread. Since
> these methods perform I/O operations (sending and receiving network packages)
> they can potentially block the execution and hence should not happen from the
> {{RpcEndpoint's}} main thread.
> I propose to make all potentially blocking operations on the
> {{FlinkKubeClient}} asynchronous so that the {{KubernetesResourceManager}}
> does not risk to block the main thread. Alternatively, we could also
> introduce a {{FlinkKubeClientAsync}} which offers asynchronous operations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
