Add an ability to run protobuf server as a Servlet 4

[trknz]

Pls add an ability to run a protobuf v3 server as a Servlet 4 on any server with the Servlet 4 support.

[ejona86]

Dump from what I wrote on SO to have the information in one place:

It does seem feasible to use the async servlet APIs to implement a gRPC server (as an alternative to the Netty server), except possibly for trailers. It's not 100% clear how to send trailers when the server is HTTP/2, since a common technique with HTTP/1 was for the servlet to manually perform chunked encoding which does not exist in HTTP/2.

[cs224]

Could someone please give a status update on this topic? Thanks!

[ejona86]

No progress. I still don't know how to send trailers in this environment.

[jnehlmeier]

JavaDoc for Java EE 8 / Servlet 4.0 describes an API to set trailers on a response.

https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletResponse.html#setTrailerFields-java.util.function.Supplier-

[ejona86]

@jnehlmeier, thank you!

I'll note one part of the docs that could be an annoyance, but I think they are talking about the remote, not the servlet (in which case we're fine to ignore it):

The RFC requires the name of every key that is to be in the supplied Map is included in the comma separated list that is the value of the "Trailer" response header. The application is responsible for ensuring this requirement is met. Failure to do so may lead to interoperability failures.

If it is for servlet interoperability we can still live with it, but it requires the application to help us out. Go already has to deal with something similar when using the Go-provided http/2 server.

[hofmanndavid]

@ejona86 can you elaborate what exactly you don't know how to do using servlets? I want to help implement this feature.

Is not this what you are referring to?

@WebServlet(asyncSupported = true)
public class MyServlet extends HttpServlet {

    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        AsyncContext asyncContext = req.startAsync(req, resp);

        // here you pass this asyncContext to any thread worker who
        // will be querying the REQ data
        // then you can send a response like

        ((HttpServletResponse)asyncContext.getResponse()).setHeader("Transfer-Encoding","chunked");
        asyncContext.getResponse().getOutputStream().write(new byte[]{});// write your bytes here
        asyncContext.getResponse().getOutputStream().flush();
        ((HttpServletResponse)asyncContext.getResponse()).setTrailerFields(() ->{
            return new HashMap<>(); // add any trailing headers
        });
        
    }
}

If there is something specific that servlet is not doing for you lets discus explicitly and I'll help.

Even if servlet spec does not allow to run gRPC server, we can still provide enough adapters so that it can run on top of jetty, undertow and tomcat. In that way at least servlets and gRPC can share the same port

An example of what I mentioned was already in the works, see wildfly mailing list

[ejona86]

@hofmanndavid, I think it would be (relatively) easy to make a servlet that would handle the I/O for gRPC. Any questions remaining in my mind are mainly on the nicest way of configuring the thing.

It would implement InternalServer and call ServerListener each inbound RPC. There's a handful of HTTP-isms that we've not split out of NettyServerHandler.onHeadersRead like we have with Http2ClientStreamTransportState, but that's not too big of a deal. For the while it could just be duplicated code.

[hofmanndavid]

Okay, Will try to get back when I have something. give me 2 weeks.

[ejona86]

CC @dapengzhang0

[dapengzhang0]

The "Trailer" in the headers is required by RFC7230 (HTTP/1.1) . So hopefully the "interoperability failure" will only occur for HTTP/1.1 clients, and HTTP/2 clients can still interoperate.

The RFC requires the name of every key that is to be in the supplied Map is included in the comma separated list that is the value of the "Trailer" response header. The application is responsible for ensuring this requirement is met. Failure to do so may lead to interoperability failures.

If it is for servlet interoperability we can still live with it, but it requires the application to help us out. Go already has to deal with something similar when using the Go-provided http/2 server.

[ejona86]

The "Trailer" header applies equally in HTTP/1.1 and HTTP/2. HTTP/2 didn't change those semantics.

[hofmanndavid]

Quoting from the protocol doc

Some gRPC implementations may allow the Path format shown above to be overridden, but this functionality is strongly discouraged. gRPC does not go out of its way to break users that are using this kind of override, but we do not actively support it, and some functionality (e.g., service config support) will not work when the path is not of the form shown above.

The initial problem I am seeing when trying to use a servlet container instead of netty is that netty owns the root path /*
In a servlet container only one deployed artifact will be able to access the root path /*, the others will have a 'contextPath' of their own.

So. We are dealing with multiple applications running in a servlet container. eg.
/ --> one-roor-app.war (app1)
/InternalService/ --> internal-app.war (app2)

There is a rule for request mapping in servlets and is that the longest path that matches is the one used to route a request to the proper app.

In case both apps will use grpc, and is what should be supported. This will happen:

1. app1 exposes a grpc called GreetService and we will be able to route it properly as it owns the root path. OK.
2. app1 exposes a grpc called InternalService and the servlet will route the request to app2. NOT_OK.
3. app2 will want to expose GreetService too!, but it will always be routed to app1. NOT_OK.

For grpc to work in a servlet container the proper way to support it IMHO is to:

1. Allow the client to add a prefix to all service names. Preferably as an optional value set when creating the channel.
2. Allow the server to be aware of that prefix.

It would be desirable to have an optional parameter in the proto file that will trigger small client code generation for adding the prefix (maybe not optional if defined in the proto file)

This will lower the entry barrier for grpc usage inside enterprises that rely a lot in application servers.

Is the reasoning correct or is there a fundamental problem?