On Mon, Nov 27, 2023 at 3:02 PM John Wilson <[email protected]> wrote:
> Is this implementation correct? > Looks fine. Is this thread safe? > Context is immutable (although the values could be mutable, but then you'd be responsible for synchronization). And the "current" Context is stored in a ThreadLocal. So, yes, it is thread-safe. Is there any way to test that implementation? > The way to give you the most confidence would be using in-process transport, like other tests. In your test case you'd make a test service implementation that does USER_ID.get(), and then send it an RPC. You may find grpc-testing-proto (io.grpc.testing.protobuf) useful, as it has a simple service you can implement for testing. That will use multiple callbacks (within the stub) and give you the highest confidence. It'd also be possible to test the interceptor "bare" by implementing a ServerCallHandler. io.grpc.testing.TestMethodDescriptors.voidMethod() is available as a MethodDescriptor. ServerCall could be a ForwardingServerCall whose delegate() throws, and then you override any methods your test needs. That may give you less confidence in your understanding of Contexts.interceptCall(). Is there any documentation that I can check to understand how Threads are > handled by the grpc server? > There's some docs on ServerCall.Listener. Basically, there's multiple callbacks, and they won't be called concurrently but may be called from different threads. So if you set a ThreadLocal in one, you may not see it in the next. Contexts.interceptCall sets the ThreadLocal, calls the callback, and then unsets the ThreadLocal before returning. -- 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/CA%2B4M1oORkBi6gRh-gjqwGeK8k7huWRmM1iH6xY-m6nsi909m-w%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
