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] > <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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. For more options, visit https://groups.google.com/d/optout.
