Repository navigation
Investigate exposing gRPC over Undertow port 8080 #301
Description
It is common that is users are exposing something over HTTP that they want to expose it using the same HTTP listener as everything else i.e. Undertow.
At the core gRPC is well defined messages making use of HTTP/2 - could these be intercepted and passed over the the gRPC server?
The path information sounds like it is /service name/method name so unless we deployed and used the service name to register with Undertow we may need to consider should be on the root context (like our HTTP upgrade support) - however the content-type would be application/grpc which maybe we could detect early in the request handling flow.
Activity
[-]Invetigate exposing gRPC over Undertow port 8080[/-][+]Investigate exposing gRPC over Undertow port 8080[/+]jmesnil commentedon Aug 20, 2026
I agree with you that gRPC traffic should go on the undertow port (
:8080) and not on another distinct port.The feature pack uses a different port because it actually starts a distinct Netty server inside WildFly that serves the gRPC traffic.
This is also why the
grpcsubsystem seems to duplicate a lot of attributes from theundertowsubsystem for any configurable knob and buttons of its HTTP stack.That's a fundamental architectural problem: the gRPC stack is running on top of Netty with its own threading model that is distinct from the XNIO thread model from Undertow and WildFly.
I don't know if it would be possible to use the https://github.com/xnio/netty-xnio-transport to start with requests on
undertow:8080and transfer it tonettywith a Netty Transport that is still backed by XNIO...Another approach would be to implement gRPC over Undertow/XNIO but @jamezp prototyped this and while it works, it relies on internal API from the gRPC project that is not meant for external use...
Another approach would be to use a version of Undertow that is backed by Netty instead of XNIO. In that case, we could perhaps use
io.grpc.nettyfor "free" (that remains to be verified).Another approach that is possible now is to rely on the
io.grpc.servletpackage to deploy gRPC service as regular Servlet. It is flagged as experimental by gRPC and might not be optimal but it has the benefits of:undertowstackjamezp commentedon Aug 20, 2026
I thought there was something about
io.grpc.servletthat wasn't working, but maybe I'm remembering wrong. However, that is definitely the right move if that works.There was a reason I didn't start with that approach, but I don't recall why.
jmesnil commentedon Sep 28, 2026
#484 is an attempt at switching to a servlet-based approach for gRPC. It delegates most of the code to
undertowand is much simpler to maintain.The servlet provided by gRPC java is
experimentalAPI (subject to change) but the surface area is smaller than the current Netty-based API.