Thanks for getting back to me.
I'm currently doing:
@Override
public Listener interceptCall(ServerCall call,
Metadata headers, ServerCallHandler next) {
if (!cacheableMethods.contains(call.getMethodDescriptor())) {
return next.startCall(call, headers);
Hi,
I have a question regarding how I can access each field of the input
request object in ServerInterceptor. The following is my code:
public ServerCall.Listener
interceptCall(ServerCall serverCall,
Metadata metadata,
ServerCallHandler serverCallHandler) {
ServerCall.Listener listener =
The idea in
https://github.com/grpc/grpc-java/issues/5414#issuecomment-468754271 should
work for your use case and the code should be almost same as that. Can you
post a snippet for your code so that we can see what went wrong? The idea
is to have your ServerInterceptor produce a ServerCall.Lis
Thank you Craig. What is the timeline for those work?
I understand the current implementation does not give us control of the
thread counts. By reading the code, the *Executor* can create as many as 2
times the cpu core threads. I have more questions here:
1. What kind of *internal* threads is
I don't think we make any guarantees about thread count right now, over and
above bounded and relatively small.
We are moving to a new design around a thing called EventEngine, which will
allow pluggable IO, thread pools, and timers. I expect once that work is
done we'll be in a position to start
Just to add some detail to this question, Alex and I work on a platform
which exerts a lot of control over threads and allocations to guarantee
high throughput and low latency. We would like to begin exposing gRPC
services from the platform without compromising performance.
Our hope was to writ
Hi all - I will use meta-data to mean generic information that is
usually sent and received besides the request/response.
So far this is what i think is the case:
(Referring to
https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md)
- For clients to send any kind of meta-dat
