This is intended to be a dumping ground for the moment.
waitForReady
channel state API to pre-connect
example NameResolver (with SPI) (both polling and non-polling)
channel/server.executor()
auth (custom client-side and server-side verification)
custom TLS, with our testing certificates (can include comments to say what's unnecessary using normal CAs)
Mutual auth TLS, also with our testing certs
Some feedback for what is missing from my experience:
More examples covering the ins and outs of wiring up Interceptors, and the mechanics of Context and tracing. I'm going by trial and error to achieve the patterns I can with go-grpc.
Basic Tracing is not configured out of the box.
I am assuming that tracing is meant to setup instrumentation similar to go-grpc when debug / event support is turned on. At least thats what I get from looking through the code and tests. I've had to manually setup everything up to zpages.
Our build is setup in Bazel, I'm quite sure I am not missing any dependencies. This is what I have done so far, I cannot contribute to the span once I leave the interceptor -- I assume I have to thread the span id through the Context ?
Tracing.getTraceConfig().updateActiveTraceParams(TraceParams.DEFAULT.toBuilder().setSampler(Samplers.alwaysSample()).build());
Tracing.getExportComponent().getSampledSpanStore().registerSpanNamesForCollection(
PciServiceGrpc.getServiceDescriptor().getMethods().stream().map(m -> m.getFullMethodName()).collect(Collectors.toList())
);
// Setup the zpages
ZPageHandlers.startHttpServerAndRegisterAll(8090);
.intercept(new ServerInterceptor() {
@Override
public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(ServerCall<ReqT, RespT> serverCall, Metadata metadata, ServerCallHandler<ReqT, RespT> serverCallHandler) {
MDC.clear();
MDC.put("grpc.method", serverCall.getMethodDescriptor().getFullMethodName());
final Map<String, String> mdcContext = MDC.getCopyOfContextMap();
final Span tracingSpan = Tracing.getTracer().spanBuilder(serverCall.getMethodDescriptor().getFullMethodName()).startSpan();
final ServerCall<ReqT, RespT> forwardedServerCall = new ForwardingServerCall.SimpleForwardingServerCall(serverCall) {
@Override
public void sendMessage(Object o) {
MDC.setContextMap(mdcContext);
super.sendMessage(o);
tracingSpan.end();
}
@Override
public void close(Status status, Metadata metadata) {
MDC.setContextMap(mdcContext);
super.close(status, metadata);
if(status.isOk()) {
tracingSpan.end();
} else {
tracingSpan.end(EndSpanOptions.builder().setStatus(io.opencensus.trace.Status.INTERNAL).build());
}
}
};
return new ForwardingServerCallListener.SimpleForwardingServerCallListener<ReqT>(serverCallHandler.startCall(forwardedServerCall, metadata)) {
@Override
public void onMessage(ReqT o) {
MDC.setContextMap(mdcContext);
super.onMessage(o);
}
};
}
});
Update: wiring up Contexts.interceptCall and using the span context ContextUtils.CONTEXT_SPAN_KEY to thread the span through the context did the trick. Looking forward to some examples showing the right way to do things.
Context example, explaining auto-propagation of deadlines and cancellation, with mention of fork().
Any doc explaining the interaction when using a set of grpc services and calling one from another would be helpful. When should I create a new context. When do I need a new thread (especially if a sync call will do an async call).
How to fail a call from a ServerInterceptor (in short: don't throw!)
a bump up.
Relationships between:
ServerInterceptorServerCallServerCall.ListenerServerCallHandlerSo is there an explanation for the relationship between
ServerInterceptor
ServerCall
ServerCall.Listener
ServerCallHandler
In an easy to read documentation
In the grpc.io google group: https://groups.google.com/g/grpc-io/c/cGGNp-Ss0V0/m/WjkI51GqCAAJ
Also there is an article https://eng.revinate.com/2017/11/07/grpc-spring-security.html that has some explanation you are looking for.
Most helpful comment
Context example, explaining auto-propagation of deadlines and cancellation, with mention of fork().