Thanks for the suggestion! That's exactly what I already implemented. However, since I still want to use `EpollEventLoopGroup` and this class is final, I ended up using dynamic proxy. The dynamic proxy redirects calls to `schedule*` to an additional `DefaultEventLoopGroup`, while the rest is handled by `EpollEventLoopGroup`. But I would prefer to use a simple setter added to `NettyChannelBuilder` instead.
On Thursday, June 1, 2023 at 8:01:05 PM UTC-7 [email protected] wrote: > One solution I can think of is for you to pass your own implementation of > EventLoopGroup where eventLoopGroup.schedule() does not call > eventLoopGroup.next() but submits it to a subset of EventLoop's that are > specifically reserved for submitted/scheduled tasks. > > NettyClientTransport calls eventLoopGroup.next() when the transport is > started so you get the 1 to 1 mapping between EventLoop and netty client > transport. > > This way you don't have to depend on any method/API from gRPC. Hope it > works? > > On Thursday, June 1, 2023 at 4:03:51 PM UTC-7 [email protected] wrote: > >> Yes, I mean NettyTransportFactory.getScheduledExecutorService. >> >> offloadExecutor does not solve the problem with eventLoopGroup used as >> as ScheduledExecutorService. >> More specifically - eventLoopGroup.schedule() is calling to >> eventLoopGroup.next().schedule() which is moving a current eventLoop >> index and making impossible to control >> 1 to 1 eventLoop to netty transport assignment. >> >> Thanks, >> Dan >> >> On Thursday, June 1, 2023 at 3:51:59 PM UTC-7 [email protected] wrote: >> >>> 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/a9925973-5cca-4444-ae06-0f499d436c80n%40googlegroups.com.
