Hi, I've noticed a behaviour recently with ClientInterceptor that was a bit surprising and I'm wondering if the documentation needs to be adjusted or whether some other adjustment needs to happen.
The issue is around the ordering of calls when multiple interceptors are present. If one uses ClientInterceptors.intercept(a,b); the documentations states that b will be invoked first. This is true for calls to the ClientCall methods, but is not for calls to ClientCalls.Listener. The calls to the ClientCall.Listener methods are in the reverse order as the calls to ClientCall methods. So if both a and b above "intercept" the ClientCall.Listener, then the ordering is something like this: // startCall: b called first a.startCall(b.startCall()) // onMessage: a called first b.onMessage(a.onMessage()) This makes it impossible for an interceptor to do something like: * setup some ThreadLocal state * invoke the next interceptor's method (e.g.: start or onMessage) * teardown ThreadLocal state This is a common pattern for setting up tracing or logging context or integrating with other frameworks that use ThreadLocal. I'm assuming this is the expected behaviour, but it is rather surprising when writing a "chain" of interceptors. Especially since the ServerInterceptor don't behave this way. Perhaps the documentation should be adjusted to reflect this more explicitly? Thanks -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/1aefb0d1-25d8-49bd-a99a-ff9d0107ce01n%40googlegroups.com.
