[C++] Completion queue request rpc tag's 'ok' boolean

633 views
Skip to first unread message

Arpit Baldeva

unread,
Aug 18, 2017, 5:17:35 PM8/18/17
to grpc.io
Hi,

In async model, from my experiments, when server shuts down, 'ok' will be false. Is there any other scenario in which it can be false? 

When the server is shutting down, I don't want to queue up another rpc request. But if the 'ok' boolean can be false in some other scenario(is there a concrete example?), I'd want to queue up another request.  

Thanks.


Christian Rivasseau

unread,
Aug 18, 2017, 5:42:28 PM8/18/17
to Arpit Baldeva, grpc.io
We've found (the hard way) that 'ok' can be false for instance when finishing a request whose client has already timed out.
Not sure if that's a bug or a feature.

@grpc team.
In any case it would be great to have formal specifications/doc for the 'ok' tag. It's also unclear to me
what's the difference between the 'ok' tag and the return value of Next().

(Other that we've observed ok to be false as described above, whereas we've never observed the result of Next() to be false
unless the server was actually shutting down).

Best,

--
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 grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
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/5c567ffd-cddb-4443-a997-6416cee8c596%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Christian Rivasseau
Co-founder and CTO @ Lefty
+33 6 67 35 26 74

Arpit Baldeva

unread,
Aug 18, 2017, 6:09:30 PM8/18/17
to grpc.io, abal...@gmail.com
Thanks for the response.

>>We've found (the hard way) that 'ok' can be false for instance when finishing a request whose client has already timed out.
Okay, So I need to put the logic in to detect if my server is shutting down. 

>>Other that we've observed ok to be false as described above, whereas we've never observed the result of Next() to be false
unless the server was actually shutting down

Looking at 1.4.2 doc, indeed, the documentation is incorrect.
/// Read from the queue, blocking until an event is available or the queue is
  /// shutting down.
  ///
  /// \param tag[out] Updated to point to the read event's tag.
  /// \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.
  bool Next(void** tag, bool* ok)

The following line 
 /// \return true if read a regular event, false if the queue is shutting down
should instead be 
 /// \return true if read an event, false if the queue is shutting down

An event can be a regular event or an irregular event (for the lack of a better term). An example would be that for a client streaming rpc, a legit incoming request is a regular event whereas a client stream close is irregular. The terminology is odd but it is what it is.

Thanks. 

On Friday, August 18, 2017 at 2:42:28 PM UTC-7, Christian Rivasseau wrote:
We've found (the hard way) that 'ok' can be false for instance when finishing a request whose client has already timed out.
Not sure if that's a bug or a feature.

@grpc team.
In any case it would be great to have formal specifications/doc for the 'ok' tag. It's also unclear to me
what's the difference between the 'ok' tag and the return value of Next().

(Other that we've observed ok to be false as described above, whereas we've never observed the result of Next() to be false
unless the server was actually shutting down).

Best,
On Fri, Aug 18, 2017 at 11:17 PM, Arpit Baldeva <abal...@gmail.com> wrote:
Hi,

In async model, from my experiments, when server shuts down, 'ok' will be false. Is there any other scenario in which it can be false? 

When the server is shutting down, I don't want to queue up another rpc request. But if the 'ok' boolean can be false in some other scenario(is there a concrete example?), I'd want to queue up another request.  

Thanks.


--
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 grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
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/5c567ffd-cddb-4443-a997-6416cee8c596%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Arpit Baldeva

unread,
Aug 18, 2017, 10:30:02 PM8/18/17
to grpc.io, Arpit Baldeva
Just wanted to clarify about the particular tag I am concerned about (request rpc tag) - the subject of my thread. From the hello world example, following one

service_->RequestSayHello(&ctx_, &request_, &responder_, cq_, cq_, this);

I do understand that in other scenarios, it is possible for to have a false value for the 'ok' bool. For example, when client finishes streaming request, the read rpc tag's 'ok' bool will be false (and other scenarios for other tags when client timed out or cancelled).

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/ywATt88Ef_I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.

Vijay Pai

unread,
Sep 13, 2017, 6:04:09 PM9/13/17
to grpc.io
Hi there,

Wanted to give a detailed reply to this question (though a bit late) since it has come up numerous times. This is for the C++ API.

Server-side request an RPC: ok indicates that the RPC has indeed been started. If it is false, the server has been Shutdown before this particular call got matched to an incoming RPC. This is actually the case that you were interested in, but I've gone ahead and documented the other cases below.

Client-side start an RPC: ok indicates that the RPC is going to go to the wire. If it is false, it not going to the wire. This would happen if the channel is either permanently broken or transiently broken but with the fail-fast option.

Client-side Write, Client-side WritesDone, Server-side Write, Server-side Finish, Server-side SendInitialMetadata (which is typically included in Write or Finish when not done explicitly): ok means that the data/metadata/status/etc is going to go to the wire. If it is false, it not going to the wire because the call is already dead (i.e., canceled, deadline expired, other side dropped the channel, etc).

Client-side Read, Server-side Read, Client-side RecvInitialMetadata (which is typically included in Read if not done explicitly): ok indicates whether there is a valid message that got read. If not, you know that there are certainly no more messages that can ever be read from this stream.

Client-side Finish: ok should always be true

Server-side AsyncNotifyWhenDone: ok should always be true

HTH!

- Vijay

Arpit Baldeva

unread,
Sep 27, 2017, 12:43:27 PM9/27/17
to grpc.io
That was helpful. Thanks.
Reply all
Reply to author
Forward
0 new messages