Hi there,

You should call Finish. It's part of the lifecycle of an async RPC and 
that's what ultimately allows the RPC to free its resources (and, as you 
noted, check its status).

Best regards,
Vijay

On Tuesday, March 5, 2019 at 1:47:04 PM UTC-8, Marek Dopiera wrote:
>
> Hi Vijay,
> thanks for your quick response.
>
> It answers part of my question. I still can't find anywhere how should I 
> react to "ok" being false. More specifically, how should I react to `ok` 
> being false after RPC invocation or after client Read. Is the stream then 
> dead and resources are released or should I still call Finish? If it is 
> the former, how should I learn the status in such a case?
>
> Thanks
>
> On Tue, Mar 5, 2019 at 10:32 PM 'Vijay Pai' via grpc.io <
> [email protected] <javascript:>> wrote:
>
>> Hi there,
>>
>> The detailed comment on "ok" is at 
>> https://github.com/grpc/grpc/blob/master/include/grpcpp/impl/codegen/completion_queue.h#L128-L170
>>  
>> . Does this answer the questions that you have about its semantics?
>>
>> Thanks,
>> Vijay
>>
>> On Tuesday, March 5, 2019 at 11:50:49 AM UTC-8, [email protected] 
>> wrote:
>>>
>>> Hi,
>>> I'm trying to find what the proper reaction to ok == false should be in 
>>> asynchronous API with streaming responses. I can't infer it from the 
>>> documentation.
>>>
>>> The example in https://grpc.io/docs/tutorials/async/helloasync-cpp.html 
>>> simply does GRP_ASSERT(ok), so I can't infer this from it either.
>>>
>>> This is my understanding of the state machine allowing to properly read 
>>> a whole stream of responses (please correct me if I'm wrong).
>>>
>>> The stream can be in one of the following states:
>>>
>>>    - NOT_CREATED (before we touch anything)
>>>    - CREATING (after calling Stub::AsyncFoo(), before 
>>>    CompletionQueue::AsyncNext() reports completion)
>>>    - PROCESSING (after calling ClientAsyncReaderInterface<>::Read())
>>>    - FINISHING (after calling calling 
>>>    ClientAsyncReaderInterface<>::Finish(), before 
>>>    CompletionQueue::AsyncNext() reports completion)
>>>    - FINISHED (the stream is dead, all resources are freed)
>>>
>>> These are the transitions between the states:
>>>
>>> State NOT_CREATED:
>>>
>>>    - Calling Stub::AsyncFoo() transitions to CREATING
>>>
>>> State CREATING:
>>>
>>>    - if CompletionQueue::AsyncNext() sets ok to true, call 
>>>    ClientAsyncReaderInterface<>::Read() and transition to PROCESSING; 
>>>    (we just got a response, BTW)
>>>    - if CompletionQueue::AsyncNext() sets ok to false, call 
>>>    ClientAsyncReaderInterface<>::Finish() transition to FINISHING
>>>
>>> State PROCESSING:
>>>
>>>    - if CompletionQueue::AsyncNext() sets ok to true, call 
>>>    ClientAsyncReaderInterface<>::Read() and transition to PROCESSING
>>>    - if CompletionQueue::AsyncNext() sets ok to false, call 
>>>    ClientAsyncReaderInterface<>::Finish() and transition to FINISHING
>>>
>>> State FINISHING:
>>>
>>>    - when CompletionQueue::AsyncNext() notifies (it will always set `ok 
>>>    == true`) transition to FINISHED; (here we learn if the stream was 
>>>    just closed or if there was an error)
>>>
>>> State FINISHED:
>>>
>>>    - nothing else can happen
>>>
>>>
>>> I have a couple of questions:
>>>
>>>    - Is this a understanding correct?
>>>    - If I wanted to finish the stream in the client, I presume, I can 
>>>    call Finish() in CREATING and PROCESSING states, right?
>>>    - Is this the same state machine on the server side or if streaming 
>>>    in the other direction?
>>>
>>> The reason I'm asking is that I'm getting a grpc assertion when calling 
>>> Finish() 
>>> after having received ok == false in state PROCESSING:
>>> grpc/src/core/lib/surface/call.cc:1853: grpc_cq_begin_op(call->cq, 
>>> notify_tag)
>>>
>>> I'd be grateful for clarification, because I'm currently don't know if 
>>> I'm misusing the library or I have a bug.
>>>
>>> Thanks in advance
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "grpc.io" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/grpc-io/pR0iKrnSO44/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/fc40a380-c482-43da-8e4d-2bb470a4e2c9%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/grpc-io/fc40a380-c482-43da-8e4d-2bb470a4e2c9%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Marek Dopiera
> [email protected] <javascript:>
>

-- 
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/f1b030c8-19ce-44bc-9dde-1d7b63e5dd19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to