Comments inline below: On Wednesday, May 31, 2023 at 6:24:56 PM UTC-7 [email protected] wrote:
Hello, I have observed that the ScheduledExecutorService utilized for setting up deadlines and exiting idle mode is obtained by calling NettyClientTransport.getScheduledExecutorService, I think you mean NettyTransportFactory.getScheduledExecutorService which is inside NettyChannelBuilder. which returns an EventLoopGroup instance that was previously set in NettyChannelBuilder.eventLoopGroup(). Is there a specific rationale behind utilizing the same EventLoopGroup instance for executing IO tasks and as a ScheduledExecutorService? NettyChannelBuilder also has offloadExecutor which lets a user to set a custom executor that will be used for (IO) operations that block or are expensive. When it is not set the builder will use a static cached thread pool (which presumably is the same as the one set from eventLoopGroup or the system default). Do you think that addresses your concern? I have identified two disadvantages associated with this approach: 1. Developers relinquish control over EventLoop to subchannel assignment, potentially leading to multiple subchannels sharing the same EventLoop. 2. The deadline task may end up in the same slow EventLoop, which subsequently requires its cancellation. To tackle these issues, I propose the addition of a setter method for a custom ScheduledExecutorService within the NettyChannelBuilder. This enhancement would enable the separate scheduling of tasks while exclusively utilizing the EventLoopGroup for IO operations. Best regards, Dan -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/884f6adf-5104-482f-82e5-611edbce5aacn%40googlegroups.com.
