I am using the Spring Boot Starter gRPC for my Reactive Spring Boot Server App Application and wanted to use a different Event Loop Group for my gRPC client (the service app talks to other services via gRPC) and according to the documentation I can do it like this:

@Bean
public GrpcChannelConfigurer keepAliveClientConfigurer() {
    return (channelBuilder, name) -> {
        if (channelBuilder instanceof NettyChannelBuilder ncb) {
            ncb.channelType(NioSocketChannel.class);
            ncb.eventLoopGroup(new NioEventLoopGroup(NettyRuntime.availableProcessors() * 2,
                    new DefaultThreadFactory("grpc-service-worker")));
        }
    };
}

which seem to work (by setting a breakpoint and seeing that it does get set), but I wanted to confirm a new thread pool is indeed being used, so I created an interceptor that simply logs I AM SPARTACUS.

@GrpcGlobalClientInterceptor
@Slf4j
public class LogGrpcInterceptor implements ClientInterceptor {

    @Override
    public <ReqT, RespT> ClientCall<ReqT, RespT> interceptCall(
            final MethodDescriptor<ReqT, RespT> method,
            final CallOptions callOptions,
            final Channel next) {

        log.info("I AM SPARTACUS");
        return next.newCall(method, callOptions);
    }
}

when i look at the logs, it seems that the new ELG is being used because the thread name of the default ELG is still being emitted (reactor-http-nio); i was assuming this will use the grpc-score-service-worker since I specified a new ELG.

20:07:02.706 [reactor-http-nio-4] INFO  c.i.p.p.c.LogGrpcInterceptor - I AM SPARTACUS

Am I correct with my assumption and there's an issue... or is the logging behavior expected? If it is expected behavior, how can I confirm that the new ELG is being used?

I am using the Spring Boot Starter gRPC for my Reactive Spring Boot Server App Application and wanted to use a different Event Loop Group for my gRPC client (the service app talks to other services via gRPC) and according to the documentation I can do it like this:

@Bean
public GrpcChannelConfigurer keepAliveClientConfigurer() {
    return (channelBuilder, name) -> {
        if (channelBuilder instanceof NettyChannelBuilder ncb) {
            ncb.channelType(NioSocketChannel.class);
            ncb.eventLoopGroup(new NioEventLoopGroup(NettyRuntime.availableProcessors() * 2,
                    new DefaultThreadFactory("grpc-service-worker")));
        }
    };
}

which seem to work (by setting a breakpoint and seeing that it does get set), but I wanted to confirm a new thread pool is indeed being used, so I created an interceptor that simply logs I AM SPARTACUS.

@GrpcGlobalClientInterceptor
@Slf4j
public class LogGrpcInterceptor implements ClientInterceptor {

    @Override
    public <ReqT, RespT> ClientCall<ReqT, RespT> interceptCall(
            final MethodDescriptor<ReqT, RespT> method,
            final CallOptions callOptions,
            final Channel next) {

        log.info("I AM SPARTACUS");
        return next.newCall(method, callOptions);
    }
}

when i look at the logs, it seems that the new ELG is being used because the thread name of the default ELG is still being emitted (reactor-http-nio); i was assuming this will use the grpc-score-service-worker since I specified a new ELG.

20:07:02.706 [reactor-http-nio-4] INFO  c.i.p.p.c.LogGrpcInterceptor - I AM SPARTACUS

Am I correct with my assumption and there's an issue... or is the logging behavior expected? If it is expected behavior, how can I confirm that the new ELG is being used?

• grpc-java
• spring-boot-reactive

Share Improve this question Follow edited Feb 3 at 14:26 Dexter Legaspi asked Feb 3 at 1:11 Dexter LegaspiDexter Legaspi 3,31211 gold badge3636 silver badges2727 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

Actually, I just confirmed this works. Validated in YourKit...so basically to confirm that the new ELG is in use you should set the logging in the application.yml or application.properties:

logging.level.io.grpcty=debug

or

logging:
  level: 
    io.grpcty: debug

With the default ELG in use you will see this:

08:53:58.789 [grpc-nio-worker-ELG-2-1] DEBUG i.g.n.s.i.gty.NettyClientHandler - ...

With the custom ELG it becomes:

09:20:57.220 [grpc-service-worker-6-7] DEBUG i.g.n.s.i.gty.NettyClientHandler - ...

...although i don't understand why the gRPC interceptor doesn't seem to be using the custom ELG? not only that...based on the log (thread name), it appears to use the application's ELG, not even the grpc worker ELG.