We use the NodeClient to execute transport actions on the local node, most notably throughout the REST layer and in plugins that do not have direct access to the TransportService. Each transport action declares an executor when registering itself with the transport service, with the expectation that it will begin execution on that executor rather than on the calling thread. In fact this forking only happens when invoked via the TransportService and not via the NodeClient, which ignores the executor and always begins the execution of the transport action on the calling thread. In the REST layer that's always going to be the transport worker handling the request. This is pretty bad because transport actions may immediately do some work that's far too expensive to run on a transport worker, such as O(#shards) coordination.
Relates #97914
Relates #92179
Relates #100111
We use the
NodeClientto execute transport actions on the local node, most notably throughout the REST layer and in plugins that do not have direct access to theTransportService. Each transport action declares an executor when registering itself with the transport service, with the expectation that it will begin execution on that executor rather than on the calling thread. In fact this forking only happens when invoked via theTransportServiceand not via theNodeClient, which ignores the executor and always begins the execution of the transport action on the calling thread. In the REST layer that's always going to be the transport worker handling the request. This is pretty bad because transport actions may immediately do some work that's far too expensive to run on a transport worker, such as O(#shards) coordination.Relates #97914
Relates #92179
Relates #100111