Server reflection service

[ejona86]

No description provided.

[zhangkun83]

The goal is to be able to propagate any reflection information, e.g., type names of the request and the response, from the generated code to the runtime. That information is specific to the marshalling system, e.g., Protobuf. I am proposing this:

1. Extend MethodDescriptor to carry marshaller-specific reflection information. For example, we will have ProtobufMethodDescriptor that carries maybe ServiceDescriptorProto, MethodDescriptorProto etc. The generated code will create ProtobufMethodDescriptor instead of the base MethodDescriptor, and pass it to ServerMethodDefinition
2. We create a new interface Reflectable which provides Collection<MethodDescriptor> getAllMethods(). A server is reflectable only if its HandlerRegistry implements this interface. (A proxy server may not be reflectable, so it doesn't necessarily implement this interface. It should forward reflection requests to the real server.).
3. The server reflection service is marshaller-specific. There is a Protobuf reflection service that works only with services that use Protobuf. It expects ProtobufMethodDescriptor from getAllMethods().

[ejona86]

That general approach SGTM, and is additive-only. We may need some other plumbing to get the HandlerRegistry to the reflection service, but that also seems it could be additive.

[nmittler]

@zhangkun83 these changes would be server-side only, correct? We probably don't want this baggage on the client-side.

[ejona86]

I could see the extra information being useful on client-side, too, and it doesn't seem that it adds almost any memory baggage or the like.

[zhangkun83]

Agreed with Eric. The extended MethodDescriptor is already in the generated code, whether or not you pass it to the client-side runtime.

[nmittler]

As it stands now, if you have an instance of your request proto is a ServiceDescriptorProto instance created automatically? Or is it created lazily?

If it is automatic, then I agree there's no problem. If it's lazy, then we should consider how much extra memory is required to hold a ServiceDescriptorProto in-mempory when the client may very well not use it.

[zhangkun83]

The descriptors are created automatically in the static block of the generated message class.

[nmittler]

@zhangkun83 ok, in that case SGTM :)

[mwitkow]

Since like support for server side reflection landed in Go: https://github.com/grpc/grpc-go/tree/master/reflection. @ejona86, any update here?

[carl-mastrangelo]

Reflection was put on hold until after GA.

[mwitkow]

@carl-mastrangelo that's ok :) Do you have a link somewhere to the GA/post-GA roadmap somewhere? :) Which quarter do you think it may happen in?

[buchgr]

@mwitkow we are pretty close https://github.com/grpc/grpc-java/milestones/1.0

[ejona86]

This is in #2360, #2509, and #2532.