On Sun, Dec 18, 2022 at 9:34 PM y <liuyaol...@gmail.com> wrote: > Thanks for answering the question! > > I have one concern on blocking the onNext call. > I assume blocking onNext call blocks grpc executor pool. > > Say I have a high QPS for streaming RPC, and one rpc request sends a lot > more streams than the others, will this starve the grpc executor pool and > block the other RPCs as well? >
Yes, that one blocking onNext() will use one thread which won't be available for other RPCs. > > Yes. I did see the manual flow control. Can you comment on the pros and > cons of using manual vs automatic? > Automatic being automatic you don't have to do much but has the potential problem of pool starvation but of course the blocked RPC anyway does not need a thread. Manual flow control gives you more control (using serverCallStreamObserver. request(1) to request next etc) and you can potentially use your thread to do your work so onNext() can return and pool available for other RPCs. > > Thanks again for helping out! > > > > On Sunday, December 18, 2022 at 5:11:59 PM UTC-7 sanjay...@google.com > wrote: > >> Take a look at >> https://github.com/grpc/grpc-java/tree/master/examples/src/main/java/io/grpc/examples/manualflowcontrol >> and disableAutoRequest() for manual flow control. >> >> I think it is okay to block on onNext() call for automatic flow control. >> Check this >> https://grpc.github.io/grpc-java/javadoc/io/grpc/stub/CallStreamObserver.html#disableAutoInboundFlowControl-- >> which says "automatic flow control where a token is returned to the peer >> after a call to the 'inbound' StreamObserver.onNext(Object) >> <https://grpc.github.io/grpc-java/javadoc/io/grpc/stub/StreamObserver.html#onNext-V-> >> has >> completed." >> >> On Friday, December 16, 2022 at 4:23:58 PM UTC-8 liuya...@gmail.com >> wrote: >> >>> Hi, >>> >>> I am trying to use bidi streaming RPC for multiple large chunks of data. >>> >>> I was wondering how to flow control is done for bidi streaming java. >>> >>> If I want to apply backpressure from server side, can I just block on >>> onNext() call? My understanding is this should be a grpc executor task I >>> shouldn't block. >>> >>> Does this mean I have to do the manual control flow to apply back >>> pressure and there is no default option? >>> >>> Thanks! >>> >> -- > 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/bb149d94-de2f-4b79-b641-b4c03c3ae7fcn%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/bb149d94-de2f-4b79-b641-b4c03c3ae7fcn%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%2BPad6g7M4ipX4qVsE-7NS%3DiD%3DJiakz5NMYp-fSpkQWyRoeOaA%40mail.gmail.com.
