Hi Sanjay, Thanks for sharing this. I will try using backpressure.
Regards, Nitish On Thursday, May 27, 2021 at 10:37:06 PM UTC+5:30 sanjay...@google.com wrote: > Just want to comment on the following : > > > I guess bi-di streams required to be used as ping-pong. Therefore, there > could be a race condition where client or server's rate of writes is more > data read causing out of sync in stream headers. > > Have you taken a look at > https://github.com/grpc/grpc-java/tree/master/examples/src/main/java/io/grpc/examples/manualflowcontrol > > ? It shows that bi-di processing doesn't have to be ping pong. > > > On Thu, May 27, 2021 at 9:31 AM nitish bhardwaj <bhardwaj...@gmail.com> > wrote: > >> Hi Eric, >> >> Thanks for sharing this information. Unary calls works fine for me. But, >> when I switched to streams both client and server side, it starts giving >> that error message. >> >> I guess bi-di streams required to be used as ping-pong. Therefore, there >> could be a race condition where client or server's rate of writes is more >> data read causing out of sync in stream headers. >> >> Please share your thoughts. >> >> Thanks & Regards, >> Nitish >> >> On Thu, 27 May 2021, 11:03 Eric Gribkoff, <ericgr...@google.com> wrote: >> >>> Hi, >>> >>> It sounds like you are trying to send multiple messages for a unary RPC, >>> which results in the "Too many responses" error. The distinction between >>> unary-response and server-streaming RPC here is about the semantics of the >>> service - namely, how many responses the server can send - and not >>> performance. Both unary and streaming RPCs use streams under the hood. It >>> sounds like you may have other synchronization challenges with your >>> specific service, which would up to your application and not gRPC's stream >>> handler to enforce, but you could also consider just changing your RPC >>> service definition to specify that the server response will be streaming. >>> >>> There was also a somewhat related discussion that you might find helpful >>> on this old question on the grpc-java repository: >>> https://github.com/grpc/grpc-java/issues/6323 >>> >>> Thanks, >>> >>> Eric >>> >>> On Wed, May 26, 2021 at 10:01 PM nitish bhardwaj <bhardwaj...@gmail.com> >>> wrote: >>> >>>> *NOTE*: The same code works perfectly if I switch streams to normal >>>> GRPC calls. >>>> >>>> But, to avoid extra latency, I need to use streams. >>>> >>>> On Thursday, May 27, 2021 at 10:25:55 AM UTC+5:30 nitish bhardwaj wrote: >>>> >>>>> Hi, >>>>> >>>>> I am trying to use bi-directional streams with JAVA. Everything works >>>>> as expected in a POC of bi-di stream where I have 1 client and server >>>>> which >>>>> reads and writes to it. >>>>> >>>>> But, it starts to break when I use the same in a mature way. >>>>> >>>>> *UseCase:* I am trying to implement gossip using grpc in Java. >>>>> Whenever any server receives a request, it gossips to the other 2 servers >>>>> using grpc streams. For an instance, I have 4 servers, server1, server2, >>>>> server3 and server4. All servers have 1 client configured to connect to >>>>> every other server. >>>>> >>>>> whenever any server receives a message, it selects the other two >>>>> servers and transmits the message and the other server does the same. >>>>> >>>>> *Issue: *As each request would be served in a new thread by grpc, I >>>>> get an error >>>>> Cancelling the stream with status Status{code=INTERNAL, >>>>> description=Too many) responses, cause=null} >>>>> >>>>> That's bcz every request is read and write to stream isn't sync as it >>>>> might not have got a response from server stream but it has written new >>>>> data to it on a new request. >>>>> >>>>> What can be done to overcome this problem? >>>>> >>>>> Thanks for the support!! >>>>> >>>> -- >>>> 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+u...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/grpc-io/7fe537c0-ac40-48eb-913c-5c1ad8be066cn%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/grpc-io/7fe537c0-ac40-48eb-913c-5c1ad8be066cn%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+u...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/grpc-io/CAO-rZtSWWfPRDh2usDbS%2BEuAPAxLXgHNLbdU4H8egDWufUucCA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/grpc-io/CAO-rZtSWWfPRDh2usDbS%2BEuAPAxLXgHNLbdU4H8egDWufUucCA%40mail.gmail.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/5cb25252-590c-4c9f-8cf0-891004154b29n%40googlegroups.com.
