Thanks for your reply. Since the exception from the marshaller in server does not reach the client, and the exception logged in server does not contain any information about microservice method which was invoked, I wanted to log microservice method name along with the parsing exception, so that we can track the microservice methods which are incompatible with the new marshaller and allow fallback to default marshaller (which is comparitively slower) for further calls.
On Friday 16 February 2024 at 01:28:15 UTC+5:30 Sergii Tkachenko wrote: > You are correct, the Marshaller won't be able to access the Context from > the interceptor. Though not exactly for the reasons you mentioned. > Unmarshalling happens prior to `ServerCall.Listener.onMessage` callback > is executed: > > 1. io.grpc.MethodDescriptor.Marshaller unmarshaller the message --> > 2. Contexts.interceptCall interceptor (ContextualizedServerCallListener > <https://github.com/grpc/grpc-java/blob/f20c853c40ef620e79b01ebcec6fcf0f667cab61/api/src/main/java/io/grpc/Contexts.java#L63>) > > restores the contexts --> > 3. ServerCall.Listener.onMessage callbacks are executed (with the context > attached). > > To answer your question, could you please provide a bit more info on what > you're trying to achieve? Why do you need microservice method name in the > marshaller? > There are a few possible approaches, but it really depends on your goals. > > Best Regards, > Sergii > > On Monday, February 12, 2024 at 8:07:03 AM UTC-8 R Chinmay wrote: > >> I have a custom implementation of request marshaller (overriding >> io.grpc.MethodDescriptor.Marshaller) >> which I want to use, but I would need context information related to the >> microservice call (specifically microservice method name being invoked). I >> tried populating it in ServerInterceptor's interceptCall. My interceptor >> code looks like this: >> @Override >> >> public <ReqT, RespT> Listener<ReqT> interceptCall(ServerCall<ReqT, RespT> >> serverCall, Metadata metadata, ServerCallHandler<ReqT, RespT> >> serverCallHandler) { >> >> Context context = Context.current().withValue(MS_METHOD_NAME, >> call.getMethodDescriptor().getFullMethodName()); >> >> return Contexts.interceptCall(context, serverCall, metadata, >> serverCallHandler); >> } >> >> But the context populated does not persist when unmarshalling of the >> request stream takes place. >> >> This is because >> io.grpc.internal.ServerImpl.ServerTransportListenerImpl#streamCreatedInternal >> >> creates new >> io.grpc.internal.ServerImpl.JumpToApplicationThreadServerStreamListener and >> populates context using >> io.grpc.internal.ServerImpl.ServerTransportListenerImpl#createContext which >> just adds deadline and serverImpl instance fields over rootContext. So, the >> information I populated was not available during unmarshalling. Also, >> populating it in onMessage would not be useful too, since >> io.grpc.internal.ServerCallImpl.ServerStreamListenerImpl#messagesAvailableInternal >> >> uses >> listener.onMessage(call.method.parseRequest(message)); >> >> so parseRequest executes before onMessage is triggered. >> >> Is there some way to pass context information to marshaller, or maybe use >> method name there. I am constructing methodDescriptor using >> io.grpc.MethodDescriptor.Builder >> > -- 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 grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/2c07b852-da95-490f-81db-c0c1b09e0310n%40googlegroups.com.
