Hi Vijay, thank you for answering, have some more confusion.
The background is I' am using GRPC 1.0.0. For Ques1, when I did the test, I found that I cannot issue another read util the previous read done event is got by completion queue. That means I only can issue the next async read request when the previous one returned by the server. otherwise, I will get an assert coredump. For Ques2, thank you for telling me the CQ result is not an error. So can I treat that an !Ok from CQ means the stream finished in server side? And what will happen when the bi-directional stream gets some failure (will it like CQ cannot get some events infinitely)? Have two more question when I went further: 1. When I call Finish on both sides, do I need to handle outstanding (or unconsumed) read/write done events first? 2. Are there any big bugs fix report of each release? Any suggestion on which version of GRPC should I choose? thanks, Yihao On Mon, May 22, 2017 at 12:28 AM, Vijay Pai <[email protected]> wrote: > Hi there, > Thanks for your questions. > > 1. You can only call 1 read and 1 write for a given stream (RPC) > concurrently without waiting for the completion queue event to return. In > the case of read, it returns when data is ready to be processed by the > application. In the case of write, the guarantee is that the return implies > that it is safe for the application to overwrite the message buffer that > was passed in. It hasn't necessarily been sent to the other side yet, but > it is committed to doing so by being in a buffer in the library or kernel. > > 2. Can you clarify what you mean by read error or write error? Error > status is not complete until Finish. Note that a CQ result of !ok is not > the same as an error - it can be a normal part of operation indicating that > there will be no further messages coming from that side of the stream. It > might indicate an error, but it might also indicate an OK status in normal > operation. > > 3. The server side doesn't ever call WritesDone; that is a client-side > thing. The server-side only calls Finish. > > On Sun, May 21, 2017 at 4:22 PM yihao yang <[email protected]> > wrote: > >> >> Hi, Vijay: >> >> I'm a little confused with the concurrency of async stream >> read/write/finish, the questions are listing below: >> 1. Can I call async stream's Read/Write multiple times event the >> completion queue not returned? >> 2. When I need to finish the stream on a write error, what should I do to >> the ongoing read? and what should I do to the ongoing write when occurs a >> read error? >> 3. Are there any different error handling operations need to be done from >> server side and client side? (as I know, both need to call >> stream->WriteDone() on write error and then stream->Finish() ) >> >> Thanks for you help, >> Yihao >> 在 2017年4月26日星期三 UTC-7下午1:05:04，Vijay Pai写道： >>> >>> Hi there, >>> >> Many of the test codes use C++ async streaming; for example >>> test/cpp/end2end/async_end2end_test or test/cpp/qps/qps_worker . >>> >>> On Thu, Apr 13, 2017 at 11:25 AM Anirudh Kasturi <[email protected]> >>> wrote: >>> >>>> Hello folks, >>>> >>>> Can you please give me pointers to an example that has an >>>> AsyncStreaming Client? >>>> >>> >>> >>>> Also, when the client is streaming data to the server, we will be >>>> basically streaming multiple messages. Is there a default timeout when the >>>> channel sees no more messages for a certain amount of time so that we can >>>> shut it down? >>>> >>> >>> There is no default timeout - the point of the async API is to give the >>> program maximum control. You can set a deadline on the Next operation by >>> using CompletionQueue::AsyncNext rather than just plain next. You can also >>> shut down the stream any time you want. >>> >>> >>>> I would like to understand the state machine of the client async >>>> streamin. How does the client keeps streaming messages to the server and >>>> when does it go to the FINISH state? >>>> >>> >>> Can you describe this further? From your paragraph above, it seems like >>> you are doing client-side 1-directional streaming, but the next sentence >>> looks like bidirectional streaming. If it's bidirectional streaming, your >>> flow will look something like: >>> >>> 1. Initiate the RPC with its completion queue and tag >>> 2. Do CompletionQueue::Next (or AsyncNext) for completion queue tags >>> 3. When you get your desired tag back, the RPC is initiated >>> 4. At that point, you can issue a Read, a Write, or one of each >>> concurrently. If you do one of each concurrently, make sure that they get >>> different tags >>> 5. Do CompletionQueue::Next and process the tags that come off it >>> 6. Loop to step 4 as long as you want to >>> 7. When you are done with Writes on this stream, initiate a WritesDone. >>> It's actually done when its CQ tag comes back >>> 8. When you are fully done with this stream, initiate a Finish. It's >>> actually done when its CQ tag comes back >>> >>> The process is similar for client-side 1-directional streaming, but >>> obviously without Reads during the main loop and with an actual response >>> object on the Finish (and not just a status). >>> >>> For each message the client sends the server has a response. In that >>>> case is it better to use pure async or asycn streaming? >>>> >>> >>> It is not always the case that the server will have a response for every >>> client send. If you mean that that's how your application is structured, >>> then that will allow you to make a pretty straightforward state machine for >>> your structures that control the stream. In general, sync streaming is >>> easier for most cases (since no completion queue manipulation) but hits >>> scalability limits since each stream gets its own thread and its own >>> completion queue. I would think that sync streaming will be a better choice >>> up to a few thousand concurrent streams; after that async streaming would >>> be preferable so that you can control threading from the application. >>> >>> >> >>>> Best, >>>> Anirudh >>>> >>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>> >>> >>>> Visit this group at https://groups.google.com/group/grpc-io. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/grpc-io/18da9b2d-a425-4c7f-8aeb-8a03c4bec1ca%40googlegroups.com >>>> <https://groups.google.com/d/msgid/grpc-io/18da9b2d-a425-4c7f-8aeb-8a03c4bec1ca%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/grpc-io. >> To view this discussion on the web visit https://groups.google.com/d/ >> msgid/grpc-io/6a956236-0f47-420f-b55f-d3edf69408de%40googlegroups.com >> <https://groups.google.com/d/msgid/grpc-io/6a956236-0f47-420f-b55f-d3edf69408de%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAKVAn%2BCY6LJziF7z-BAC5LGxhuf5%2BZArAE1b9_1cTOiT0WFxRg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
