gRPC Java - how to efficiently work with metadata?

[slili...@onemarketnetwork.com]

I have started working with gRPC fairly recently and really like a lot of aspects of it - thanks to all who contributed to it! But a couple of design decisions don't make sense to me (at least not yet!). Any comments/responses to the question in the subject line would be greatly appreciated.

A bit more background. Java server side code generated from proto3 files doesn't have any simple way to access the headers/trailers of the incoming message. It looks like the only way to access them is to create a custom call interceptor, capture and store values in thread-local variables for the subsequent access in the method implementations. It's error prone and rather cumbersome. 

Go's implementation makes it much simpler to do that, thanks to metadata package (https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md). Any reason why a similar facility doesn't exist in Java? https://github.com/grpc/grpc-java/blob/master/stub/src/main/java/io/grpc/stub/MetadataUtils.java provides some options (MetadataCapturingClientInterceptor), but is explicit that it's designed for testing purposes. Or am I missing something?

Thanks,

Sergei

[Carl Mastrangelo]

Responses inline:

On Friday, March 16, 2018 at 5:13:07 PM UTC-7, slili...@onemarketnetwork.com wrote:

I have started working with gRPC fairly recently and really like a lot of aspects of it - thanks to all who contributed to it! But a couple of design decisions don't make sense to me (at least not yet!). Any comments/responses to the question in the subject line would be greatly appreciated.

A bit more background. Java server side code generated from proto3 files doesn't have any simple way to access the headers/trailers of the incoming message. It looks like the only way to access them is to create a custom call interceptor, capture and store values in thread-local variables for the subsequent access in the method implementations. It's error prone and rather cumbersome. 

Protobuf is gRPC agnostic.   gRPC is protobuf agnostic.  Neither of them know about each other, and this allows you to avoid either one if you don't want them.   We actually have examples that don't use Protobuf in gRPC, particularly in our benchmarks.

The reason metadata is harder to get to is because it would complicate the stub API.   gRPC Java opts for extremely simple stubs at the cost of some functionality.   Using the Interceptor (or the ClientCall / ServerCall api) allows you access to them, presumably so you can modify the call.   

Using them is more advanced, but we have helper classes to avoid errors.  Take a look at SimpleForwardingClientCall  to help you stub our most of the functionality in your interceptor.  It is expected to *not* use thread local variables, but the Context, which is propagated correctly across thread boundaries.