A question about the solution for Context / Scoped Beans

[ChaselX]

The context

As the doc said "In grpc-java different steps in the message delivery / request process can and will run in different threads. This is
not only but especially relevant for streaming calls. Avoid using ThreadLocals inside your ServerInterceptors and
grpc service method implementations (in the entire grpc context). When it comes down to it, the preparation phase, every
single message and the completion phase might run in different threads. If you wish to store data for the duration of
the session, do so either using grpc's Context or grpcRequest scoped beans."

So you defined the GrpcRequestScope.

The question

But I look up the source code, The Only Implement for io.grpc.Context.Storage is io.grpc.ThreadLocalContextStorage. This is also based on ThreadLocal.

So how can it useful for ** different steps use different threads** ??

If this question could be picked , I will be very grateful. Thank you

[ST-DDT]

You can theoretically use ThreadLocals while a single Message is processed.

• If you have an unary or server streaming call, you can use thread locals throughout ServerInterceptor#interceptCall, ServerCallListener#onMesssage, ServerCallListener#onHalfClose and your entire method implementation.
• If you have a client or bi-directional streaming call, then you can use a thread local in ServerCallListener#interceptCall and your main implementation of your method implementation. You can use a separate one for ServerInterceptor#onMesssage and the StreamObserver#onNext returned by your method implementation. However, you cannot use them across each other.

The pairs of working methods might change in a future release (or might have already) , so be careful to do it "right".

The following implementation uses spring security's (ThreadLocal) storage to set the authentication, please note that the authentication is set before each method (ServerCallListener + ServerInterceptor) call and removed afterwards:

DefaultAuthenticatingServerInterceptor
AbstractAuthenticatingServerCallListener

The GrpcContext works in a similar fashion. The Thread local is populated right before each step and immediately cleared afterwards,

WARNING: Do not try to use Thread-Locals across these borders or you end up in something, that "works" in low load environments and fails in production.

I explicitly added a test to this project to ensure that everything works in a concurrent environment.
ConcurrentSecurityTest

If you aren't careful you end up like the examples mentioned in this comment:
LogNet/grpc-spring-boot-starter#61 (comment)

Does this solve your question?