[
https://issues.apache.org/jira/browse/FLINK-17024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163057#comment-17163057
]
Till Rohrmann commented on FLINK-17024:
---------------------------------------
I guess the main benefit would be not having to introduce a new {{Executor}} if
you just want to run some futures outside of the {{RpcService}} thread pool. It
would be somewhat similar to {{ForkJoinPool#commonPool()}} which is used when
not specifying an explicit executor with any of the async {{CompletableFuture}}
calls. But for any heavy workloads it is usually a better idea to introduce a
dedicated thread pool.
Since it is always a good idea to not offer ways to shoot yourself into the
foot, it might actually be better to completely remove
{{RpcService.getExecutor}} and {{RpcService.getScheduledExecutor}} so that
users don't use it wrongly. Hence, +1 for Chesnay's proposal.
> Make AkkaRpcService#getExecutor return a custom thread pool
> -----------------------------------------------------------
>
> Key: FLINK-17024
> URL: https://issues.apache.org/jira/browse/FLINK-17024
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Coordination
> Reporter: Yang Wang
> Priority: Major
>
> Follow the discussion in this PR[1].
> Currently, {{AkkaRpcServcie#getExecutor}} returns Akka's underlying
> dispatcher thread pool. It should not be used since it will take the risk to
> affect the main thread of rpc endpoint. We could return a custom thread pool
> instead. The it is safe to used for some I/O operations in the
> {{RpcEndpoint}}, for example, {{stopPod}} in {{KubernetesResourceManager}}.
> An elastic thread pool(from 4 up to 16) is enough.
>
> [1]. [https://github.com/apache/flink/pull/11427#discussion_r402738678]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
