I agree with you, but it really happend, and in high frequency, maybe it's a bug? It's a unary RPC.
在 2017年9月6日星期三 UTC+8上午12:26:14，Mark D. Roth写道： > > If the tag being returned from the completion queue is the result of a > Finish() call, then I think ok should always be true, even if the status is > not okay. This is because the underlying op in C-core always succeeds: > > > https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h#L470 > > Is this a unary or streaming RPC? If it's streaming, then perhaps you're > getting a tag back from something other than Finish() (e.g., a send or recv > message op)? In that case, the individual op may fail but the call's > overall status will not yet have been received -- that doesn't happen until > after the tag from Finish() is returned. > > On Sun, Sep 3, 2017 at 6:57 PM, 谭锦彪 <[email protected] <javascript:>> > wrote: > >> Hi Roth, >> >> Thanks for your reply, about the refer to tag, you can see >> greeter_async_client2.cpp, my client code is just like it, but the server >> code has complex work to do. >> Sometimes, ok is false but call->status.ok() is true, >> and call->reply.message() is right. That happens very frequent in my >> situation, and currently, I ignore it, do not check ok, and the program >> working properly, but I worried if there will some undefined things >> happen. >> So that confused me, if the response of the grpc server is correct, why >> the ok equals false? >> void AsyncCompleteRpc() { >> void* got_tag; >> bool ok = false; >> >> // Block until the next result is available in the completion >> queue "cq". >> while (cq_.Next(&got_tag, &ok)) { >> // The tag in this example is the memory location of the call >> object >> AsyncClientCall* call = >> static_cast<AsyncClientCall*>(got_tag); >> >> // Verify that the request was completed successfully. Note >> that "ok" >> // corresponds solely to the request for updates introduced >> by Finish(). >> GPR_ASSERT(ok); >> >> if (call->status.ok()) >> std::cout << "Greeter received: " << >> call->reply.message() << std::endl; >> else >> std::cout << "RPC failed" << std::endl; >> >> // Once we're complete, deallocate the call object. >> delete call; >> } >> } >> >> >> 在 2017年9月1日星期五 UTC+8下午10:10:25，Mark D. Roth写道： >>> >>> I'm not sure what you mean when you refer to tag->status and >>> tag->reply. The gRPC API does not define a particular API for the tag; >>> that's entirely up to your application code, so I have no idea what those >>> fields represent or how they are being set. >>> >>> Yang's earlier description is correct: the ok parameter is an indication >>> of whether the operation corresponding to the returned tag was successful. >>> What a failure means depends on what the operation was. If it was a >>> RequestCall(), then it means that the completion queue is shutting down and >>> you can stop listening for new calls. For any request as part of a call >>> (e.g., a read or a write), it means that there was a problem with the >>> operation and you should call Finish() to get the call's final status. >>> >>> On Thu, Aug 31, 2017 at 11:30 PM, 谭锦彪 <[email protected]> wrote: >>> >>>> Hi >>>> >>>> I meet the situation that the Next return true, but ok==false, howerer, >>>> the content of the tag is right, tag->status.ok() return true, tag->reply >>>> is right too, That confuse me, >>>> why would this situation happen? Could I ignore the check of ok? >>>> >>>> 在 2017年8月2日星期三 UTC+8上午6:57:16，Yang Gao写道： >>>> >>>>> Usually we have a loop calling Next and when we are sure there will be >>>>> no more work adding to the completion queue we call completion queue's >>>>> Shutdown method to shutdown the queue. >>>>> It will in turn cause the Next to return false and it can be used to >>>>> break out of the loop. >>>>> >>>>> The ok parameter is an indication of the success of that particular >>>>> operation and usually is not related to the cq life time management. >>>>> >>>>> >>>>> On Monday, July 10, 2017 at 2:32:37 AM UTC-7, Przemysław Sobala wrote: >>>>>> >>>>>> Hello >>>>>> What is the difference between method's >>>>>> bool CompletionQueue::Next(void** tag, bool* ok) >>>>>> return value and 2nd parameter's value? >>>>>> >>>>>> Reading docs, it says: >>>>>> /// \param ok[out] true if read a regular event, false otherwise. >>>>>> /// \return true if read a regular event, false if the queue is >>>>>> shutting down >>>>>> >>>>>> Following the example: >>>>>> while (true) { >>>>>> // Block waiting to read the next event from the completion >>>>>> queue. The >>>>>> // event is uniquely identified by its tag, which in this case >>>>>> is the >>>>>> // memory address of a CallData instance. >>>>>> // The return value of Next should always be checked. This >>>>>> return value >>>>>> // tells us whether there is any kind of event or cq_ is >>>>>> shutting down. >>>>>> GPR_ASSERT(cq_->Next(&tag, &ok)); >>>>>> GPR_ASSERT(ok); >>>>>> static_cast<CallData*>(tag)->Proceed(); >>>>>> } >>>>>> it breaks whether the return value or ok parameter is false. >>>>>> But in the production environment maybe I can break the loop when the >>>>>> queue is shutting down (based on return value) and continue when ok >>>>>> parameter's value is false? >>>>>> What is the most preferable approach? Should I consider both of them >>>>>> as the same and break on false as in the example? >>>>>> >>>>>> -- >>>>>> regards >>>>>> Przemysław Sobala >>>>>> >>>>> -- >>>> 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/35ece217-c182-4dd9-b779-bbe8bf6b58d3%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/grpc-io/35ece217-c182-4dd9-b779-bbe8bf6b58d3%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Mark D. Roth <[email protected]> >>> Software Engineer >>> Google, Inc. >>> >> -- >> 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/f2d9dbda-9a4a-4283-ab13-0cf57b0547a9%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/f2d9dbda-9a4a-4283-ab13-0cf57b0547a9%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mark D. Roth <[email protected] <javascript:>> > Software Engineer > Google, Inc. > -- 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/d5a6f5b7-b118-4ce3-b800-2f42c2304f8b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
