You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a Spring Boot application serving HTTP requests in a multitenant architecture. For HTTP requests, client identity is extracted from a header and stored in a ThreadLocal. Since Tomcat ensures a single request is served by a single thread, this approach works well.
Now, the application is being extended to serve gRPC requests (unary calls only). I understand there are concerns about using ThreadLocal in gRPC, even for unary calls. However, my testing shows no issues so far.
To address potential concerns, I explored using the gRPC Context API to propagate request-scoped data, such as client identity, across multiple server interceptors. Below is an example of my implementation:
Example Implementation:
Is it acceptable to use ThreadLocal for storing request-scoped data in gRPC unary calls?
If not, why is it discouraged, considering the synchronous nature of unary calls?
Using gRPC Context for Propagation:
In the implementation above, does the creation of a new Context object using Context.withValue() ensure proper isolation
of data between requests?
Is manual cleanup of the previous Context required, or does gRPC handle this automatically?
How can I ensure client-specific data stored in the Context is not inadvertently leaked or reused in subsequent requests?
MDC and Logging in gRPC Unary Calls:
Is it appropriate to use MDC (which relies on ThreadLocal) for logging context in gRPC unary calls?
If so, is overriding onComplete() and onCancel() sufficient to ensure proper cleanup of MDC after the request lifecycle?
Should other methods like onHalfClose() be overridden to handle edge cases?
If MDC is discouraged, what alternative approach should I use for propagating logging context across interceptors?
The application's environment
Which versions do you use?
Spring (boot): 2.7.7
grpc-spring-boot-starter: 3.1.0.RELEASE
java: 17
The text was updated successfully, but these errors were encountered:
I have a Spring Boot application serving HTTP requests in a multitenant architecture. For HTTP requests, client identity is extracted from a header and stored in a ThreadLocal. Since Tomcat ensures a single request is served by a single thread, this approach works well.
Now, the application is being extended to serve gRPC requests (unary calls only). I understand there are concerns about using ThreadLocal in gRPC, even for unary calls. However, my testing shows no issues so far.
To address potential concerns, I explored using the gRPC Context API to propagate request-scoped data, such as client identity, across multiple server interceptors. Below is an example of my implementation:
Example Implementation:
Specific Questions:
Is it acceptable to use ThreadLocal for storing request-scoped data in gRPC unary calls?
If not, why is it discouraged, considering the synchronous nature of unary calls?
In the implementation above, does the creation of a new Context object using Context.withValue() ensure proper isolation
of data between requests?
Is manual cleanup of the previous Context required, or does gRPC handle this automatically?
How can I ensure client-specific data stored in the Context is not inadvertently leaked or reused in subsequent requests?
Is it appropriate to use MDC (which relies on ThreadLocal) for logging context in gRPC unary calls?
If so, is overriding onComplete() and onCancel() sufficient to ensure proper cleanup of MDC after the request lifecycle?
Should other methods like onHalfClose() be overridden to handle edge cases?
If MDC is discouraged, what alternative approach should I use for propagating logging context across interceptors?
The application's environment
Which versions do you use?
The text was updated successfully, but these errors were encountered: