grpc-netty-shaded incompatible with netty-transport-native-epoll

[snowp]

Please answer these questions before submitting your issue.

What version of gRPC are you using?

1.13.1

What did you expect to see?

I expected to be able to specify EpollEventLoopGroup and EpollDomainSocketChannel as the eventLoopGroup and channelType when using grpc-netty-shaded.

Due to netty-shading rewriting the package path, grpc-netty-shaded isn't compatible with regular netty packages. This is generally fine because grpc-netty-shaded contains all classes necessary to use netty with grpc, but jars like netty-transport-native-epoll are missing, making it impossible (I think?) to use them with grpc-netty-shaded.

Thoughts on this? Should netty-transport-native-epoll/netty-transport-native-kqueue be shaded into grpc-netty-shaded?

[ejona86]

Yes, it is incompatible. There's only two choices:

1. If you're using something like epoll/kqueue native transports, use grpc-netty instead
2. Add epoll/kqueue for all users, increasing everyone's binary size

At present (1), makes the most sense since you can't actually enable epoll/kqueue without using gRPC+Netty-specific APIs, which means using shaded names. At some point (maybe this quarter?) we'll have some built-in Unix Domain Socket handling, which will muddy the waters.

Are you wanting the performance, unix socket support, or something else?

[snowp]

We need it for unix socket support. Sounds like we should be moving back to grpc-netty until there's better built in support for unix sockets. Is there an issue tracking that work?

[njhill]

There's also this https://github.com/HubSpot/grpc-netty-shaded-epoll

[ejona86]

I've created a tracking issue: #4750. Note that #3085 is the main work.

[SamBarker]

I think this was fixed by #5581

[ejona86]

Yep. Fixed by #5581