Accessing NettyServiceHandler for grpc-java

[Doug DesCombaz]

I have a working example using the NettyServerBuilder and protobufs that create an endpoint service and provides me with the Java representation of what I want. 

I don't need the server/endpoints. I really just want the codec (or whatever marshalls the bytes to the Java object). 

The reason is, I have an existing Netty based server, and I would prefer to just plug in a GRPC pipeline handler, and do some work, and send it along the way. So, in other words, I have existing common business logic, but a couple of different interfaces (HTTP, and now GRPC). 

Some issues: 
1)  I don't think I can use the NettyServerBuilder() because it expects a shadowed version of the event loops. In other words, the GRPC project brings in the Netty code and repackages, so many classes can't be used back-and-forth. 

2) The NettyServerHandler isn't exposed in the package. 

Some possibilities:
1) I think it would be possible if I forked the grpc-java: /netty... code. Probably expose the underlying Context/Channel/Pipelines to the generated service stub. Maybe, but also not too trivial. 

2) Ultimately, I can just run two servers, and send it over a socket, but I was hoping to not add a hop. 
3) Any other ideas ?

Thanks for any thoughts,

-Doug

[Eric Anderson]

On Tue, Jun 14, 2022 at 6:39 PM Doug DesCombaz <do...@descombaz.com> wrote:

Some issues: 
1)  I don't think I can use the NettyServerBuilder() because it expects a shadowed version of the event loops. In other words, the GRPC project brings in the Netty code and repackages, so many classes can't be used back-and-forth. 

That's if you are using grpc-netty-shaded. The grpc-netty artifact doesn't shade Netty, so you can share event loops.

2) The NettyServerHandler isn't exposed in the package. 

And if it were it wouldn't really be useful. It is still using the old monolithic callback-based Netty HTTP/2 API so can't intermix with other HTTP handlers for the same connection. I don't think we'll ever go the Http2MultiplexCodec route, but getting on the Http2FrameCodec would allow some of these things to be possible. Although it would still take some redesign/refactoring in gRPC as RPC handling is intermixed with connection handling. To make something where you would implement your service using Netty APIs would essentially end up as a rewrite.

Some possibilities:
1) I think it would be possible if I forked the grpc-java: /netty... code. Probably expose the underlying Context/Channel/Pipelines to the generated service stub. Maybe, but also not too trivial. 

2) Ultimately, I can just run two servers, and send it over a socket, but I was hoping to not add a hop. 
3) Any other ideas ?

Port sharing is not really in the cards right now. If you tried to fork the code I think you'd discover rapidly its architecture is vastly different from what you're searching for.

You could use LocalChannel instead of having a second socket, but the gRPC code would still be expecting HTTP/2 frames.

Making a gRPC server that only handles the RPC stuff isn't that hard of an affair. It wouldn't be all that bad for someone to make a gRPC Netty handler to use in Netty-based applications.

[Doug DesCombaz]

Thank you very much for your thoughts Eric.