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]> 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/ms >>> gid/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]. > 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/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]> 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/CAJgPXp4qTU-7qhN5GZC9003%3Dd-JC9Tp%2B1qOHn5ZjCD3km%3DQbFw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
