Can you put together a standalone example that reproduces the problem? If so, please file a bug that includes the example, and someone will take a look.
On Tue, Sep 5, 2017 at 5:54 PM, 谭锦彪 <[email protected]> wrote: > 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/c >> odegen/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/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]. >>> 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/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/d5a6f5b7-b118-4ce3-b800-2f42c2304f8b%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/d5a6f5b7-b118-4ce3-b800-2f42c2304f8b%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/CAJgPXp6jDq8%3DyaPg_-Q1UYvvHEKGS-jLRU--ctTAr%2BMg1A%3DcEg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
