On Tue, Nov 14, 2023 at 11:44 AM Krishna Sai Veera Reddy < krishnasaiveerareddy...@gmail.com> wrote:
> >Is there a problem with running it on another thread? > This basic rate limiter just increments/decrements a counter and nothing > more so it seems wasteful to use a thread to do this. > "wasteful." It isn't generally wasteful as the same thread will be used to process the request. It isn't "waste" as much as "what level of rejection rate does my server need to support" and whether doing the processing in another thread is able to satisfy that need. Doing the processing in another thread isn't very expensive, depending on your baseline for cost: it is a few atomic writes and some latency. The request will be deserialized before calling the interceptor, which can be considerable CPU. To delay that until after your interceptor, use ServerInterceptors.useInputStreamMessages(). For such cases how do we switch executors? Even if it isn't recommended I > would love to know how this can be done theoretically. Thank you for your > response! > To just use an interceptor: To have the application code run in a different thread than the interceptor, you'd need to wrap all the ServerCall.Listener methods and schedule them on your own executor. You need to make sure the callbacks don't execute concurrently, so probably would use Guava's MoreExecutors.newSequentialExecutor(Executor). To use ServerCallExecutorSupplier with an interceptor: it's a bit tricky. You could make a ServerCallExecutorSupplier that detects if the rate limit is already exceeded and returns a direct executor. Then the interceptor detects it is running in the direct executor and fails the RPC. On Tuesday, November 14, 2023 at 10:24:53 AM UTC-8 Eric Anderson wrote: > >> On Wed, Nov 8, 2023 at 9:46 AM Krishna Sai Veera Reddy < >> krishnasaiv...@gmail.com> wrote: >> >>> I am implementing a gRPC service and have a use-case where I need to >>> rate limit RPC calls but would like the rate limiting server interceptor to >>> run directly on the network thread as it is non-blocking(Using direct >>> executor). >>> >> >> Is there a problem with running it on another thread? Even for >> fully-async workloads we would discourage using direct executor as it can >> significantly impact latencies. >> > -- > 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 on the web visit > https://groups.google.com/d/msgid/grpc-io/8d96019c-584c-4497-bcb7-821ee48b6b39n%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/8d96019c-584c-4497-bcb7-821ee48b6b39n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oMMkOVgrfW3G3dy%2BB_ug%2BONnEd5MoQP3isp6TJDJgoesA%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
