Grpc Client in Tests fail when Running on Linux with Netty Native Transports

[pcasaes]

Describe the bug

Used Getting Started and created a project with the grpc extension.

Added linux netty native transports and enabled quarkus.vertx.prefer-native-transport.

When running tests on linux, fails with:

Caused by: java.lang.IllegalStateException: incompatible event loop type: io.netty.channel.epoll.EpollEventLoop
        at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:472)

Expected behavior

Tests should pass

Actual behavior

Test fails with

Caused by: java.lang.IllegalStateException: incompatible event loop type: io.netty.channel.epoll.EpollEventLoop
        at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:472)

How to Reproduce?

Reproducer: https://github.com/pcasaes/test-grpc-client

On windows and mac can use docker to run on linux vm

docker run --rm -it -v .:/work maven:3.9-amazoncorretto-21 /bin/bash

cd work
mvn clean verify

Output of uname -a or ver

Linux 09dcf29f42c6 6.10.14-linuxkit #1 SMP Fri Nov 29 17:22:03 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

Output of java -version

OpenJDK 64-Bit Server VM warning: Unable to get SVE vector length on this system. Disabling SVE. Specify -XX:UseSVE=0 to shun this warning. openjdk version "21.0.6" 2025-01-21 LTS OpenJDK Runtime Environment Corretto-21.0.6.7.1 (build 21.0.6+7-LTS) OpenJDK 64-Bit Server VM Corretto-21.0.6.7.1 (build 21.0.6+7-LTS, mixed mode, sharing)

Quarkus version or git rev

3.21.0

Build tool (ie. output of mvnw --version or gradlew --version)

OpenJDK 64-Bit Server VM warning: Unable to get SVE vector length on this system. Disabling SVE. Specify -XX:UseSVE=0 to shun this warning. Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) Maven home: /usr/share/maven Java version: 21.0.6, vendor: Amazon.com Inc., runtime: /usr/lib/jvm/java-21-amazon-corretto Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "6.10.14-linuxkit", arch: "aarch64", family: "unix"

Additional information

The issue seems to be in the GRPC Client. Although the client is in the test code in this reproducer, I suspect the issue will also happen in production code.

Disabling GRPC client's use-vertx-event-loop will allow the client to work. The issue seems to be introduced by this PR #46198

quarkus:
  vertx:
    prefer-native-transport: true
  grpc:
    clients:
      "test":
        use-vertx-event-loop: false

Disabling native-transport will also allow the the client to work. Using the new Vert.x gRPC on the server has no impact.

[quarkus-bot]

/cc @alesj (grpc), @cescoffier (grpc,netty), @franz1981 (netty), @jponge (netty)

[pcasaes]

The issue also happens on mac (no need for a linux vm on mac) with its native transports:

        <dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-transport-native-kqueue</artifactId>
            <classifier>osx-x86_64</classifier>
        </dependency>

        <dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-transport-native-kqueue</artifactId>
            <classifier>osx-aarch_64</classifier>
        </dependency>

Caused by: java.lang.IllegalStateException: incompatible event loop type: io.netty.channel.kqueue.KQueueEventLoop
        at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:472)

[franz1981]

Thanks for reporting 🙏
Probably the condition at https://github.com/franz1981/quarkus/blob/bf12ff2c0ca7f3d7b96e116c0f030026662175b8/extensions/grpc/runtime/src/main/java/io/quarkus/grpc/runtime/supports/Channels.java#L215 is not right and it should be !isNativeTransportEnabled

Can you give it a shot?
And feel free to send the fix, if I am right, since will take some hours before my job way start here

[pcasaes]

Sure thing!

#47025

Too bad about not being able to work with native transports here.

It did test against the reproducer on both linux and macos. All is well.

[franz1981]

Too bad about not being able to work with native transports here.

I know - I made it on purpose since is not "officially" supported - but if you want I can raise the point with @cescoffier and I think we can find a way to detect which native transport is used and just use the "right" channel type there, to make it work.
The same applies to the mongo DB client which has the same limit.
In any case what I have done should already improve immeensely the grpc client perf & behaviour (for NIO at least)

[pcasaes]

Maybe the change should be made to the grpc-java and keep this all internal.

Instead of requiring channel type or factory when setting the eventLoopGroup as stated here
https://github.com/grpc/grpc-java/blob/master/netty/src/main/java/io/grpc/netty/NettyChannelBuilder.java#L355-L357

When not provided, It could derive the type by inspecting the given eventLoopGroup's type. It's reflection which isn't ideal but that project already is doing reflection to figure this stuff out:
https://github.com/grpc/grpc-java/blob/master/netty/src/main/java/io/grpc/netty/Utils.java#L120-L137