I think more usecase can be some modifications in marshalling based on some header field, so in my usecase, I am using a custom marshaller with json request and I need to combine the data from header / context and the request in one final request class which will be processed.
On Thursday, February 22, 2024 at 4:11:08 AM UTC+5:30 Sergii Tkachenko wrote: > Thank you for the detailed explanation. > > Since the only thing you need is the method name, consider adding a > methodName parameter to your marshaller class. Then, when building the > service definition, you can create an instance of your marshaller per > method, and provide the method name as a constructor/builder argument. > Would this solution work for you? If not, I'd be curious to know why. > > - Sergii > > > On Monday, February 19, 2024 at 6:37:49 AM UTC-8 R Chinmay wrote: > >> 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 visit https://groups.google.com/d/msgid/grpc-io/c4b92f01-cbca-4cdd-b487-d10858b1ac66n%40googlegroups.com.
