Add a simple `StreamMessageAndWriter` for a dedicated event loop

A DefaultStreamMessage is a thread-safe StreamMessageAndWriter for multiple producder. Some technics are used for concurrency such as:

• MpscChunkedArrayQueue https://github.com/line/armeria/blob/f0252bd457cc5e4fd3e70382debfb8cbadd74bbb/core/src/main/java/com/linecorp/armeria/common/stream/DefaultStreamMessage.java#L106
• Some volatile fields https://github.com/line/armeria/blob/f0252bd457cc5e4fd3e70382debfb8cbadd74bbb/core/src/main/java/com/linecorp/armeria/common/stream/DefaultStreamMessage.java#L89-L97
• CAS operations https://github.com/line/armeria/blob/f0252bd457cc5e4fd3e70382debfb8cbadd74bbb/core/src/main/java/com/linecorp/armeria/common/stream/DefaultStreamMessage.java#L478

In some cases, we can write and read elements in a single event loop. For example, the HttpObjects for DecodedHttpRequest and DecodedHttpResponse are always written in an event loop with channelRead event. https://github.com/line/armeria/blob/002e24970fb71cbf7bb27697f95367499a19588c/core/src/main/java/com/linecorp/armeria/client/Http1ResponseDecoder.java#L185 https://github.com/line/armeria/blob/6f93315ba003f167788d5f4f1c6d7464387444bc/core/src/main/java/com/linecorp/armeria/server/Http1RequestDecoder.java#L248

Furthermore, we don’t directly expose the DecodedHttpRequest and DecodedHttpResponse for gRPC services and clients. It also is subscribed by the event loop which is used for writing. https://github.com/line/armeria/blob/207c5e038f59802dca769936a50e219a5fe308ea/grpc/src/main/java/com/linecorp/armeria/server/grpc/ArmeriaServerCall.java#L645-L649 It would be efficient to add a non-thread-safe version of StreamMessageAndWriter and use it for handling encoding and decoding HTTP layer for gRPC service and client.

[ikhoon]

we can’t prevent subscribers from calling subscribe(), request() and close() on DecodedHttp[Request|Response].

That is true for HTTP protocol and REST. A HttpRequest and Response is directly exposed to users with HttpService and WebClient. Users can subscribe to the Publisher with their own Subscriber. Some thread safety is required for the Publisher.

However, We don’t expose our HttpRequest to users for gRPC services.

• ArmeriaServerCall subscribes to HttpRequest with ctx.eventLoop() for decoding gRPC frames
• The decoded gRPC messages passed to a gRPC stub. Finally users will get a unary message or a stream messages through gRPC’s StreamObserver

Though a service is RPC, a HttpRequest is exposed to users by decorators. But users can not subscribe to the Publisher directly because Armeria’s StreamMessage should be subscribed only once. I think the stream duplicator could take care of the safety for decorators.

One thing I think we can do is modify to not use MpscChunkedArrayQueue since write signals will only be performed from armeria event loops.

Agreed. We don’t need to use MpscChunkedArrayQueue for decoded request and response.

[ikhoon]

The current code currently doesn’t know whether a request is grpc (and whether to create a thread-unsafe DecodedHttpRequest) in Http[1|2]RequestDecoder. Maybe we can looks at a header value like content-type for this though…

• Prepration: Extract the media type defined in GrpcSerializationProvider to MediaType such as MediaType.GRPC, MediaType.GRPC_JSON and so on. It is also convenient to add a utility for gRPC media type - mediaType.isGrpc(). https://github.com/line/armeria/blob/9e601afd504a4cb31f6e811cb66b9c535dd026d3/grpc/src/main/java/com/linecorp/armeria/internal/common/grpc/GrpcSerializationFormatProvider.java#L35-L41

• Predicate:

  1. armeria-grpc should be added as a dependency. We can statically know with Class.forName("c.l.a.g.GrpcService").
  2. Use an unsafe StreamMessage if req.contentType().isGrpc() returns true.

I guess this means if the user calls subscribe/abort, the grpc request fails to reach the designated grpc service.

• subscribe
  • Users should not directly subscribe to a request/response during decorating a service. It prevents a gRPC service from subscribing to the stream. So StreamMessageDuplicator must be used for subscribing to a stream from outside of Service. The following Javadoc would help you learn the mechanism. https://github.com/line/armeria/blob/87602a8d52bb94c8bfdec28f48687d3ee4100192/core/src/main/java/com/linecorp/armeria/common/stream/StreamMessageDuplicator.java#L29-L43
• abort
  • Good point. If users abort a stream outside of an event loop, that could result in a corrupted state such as a concurrent modification. How about forcibly executing abort() with in the event loop in DecodedHttpRequest. https://github.com/line/armeria/blob/dbfc1cdbbacb7c15d8128b5b40972de28a82930e/core/src/main/java/com/linecorp/armeria/server/DecodedHttpRequest.java#L48

    void abort() {
        if (executor.inEventLoop()) {
            abort0();
        } else {
            executor.execute(this::abort0)
        }
    }