Responses inline: On Tue, Aug 28, 2018 at 6:25 PM yashkt via grpc.io <[email protected]> wrote:
> Also, this doc might be outdated but it does say that server can cancel > RPCs https://grpc.io/docs/guides/concepts.html#cancelling-rpcs > I think C is the only implementation with a server side API that allows this. Since the proposal allows logging a C server side cancel in a sensible way, I think we can add a comment about this possibility but do not attempt to log the server cancellation attempt. > > On Tuesday, August 28, 2018 at 5:44:33 PM UTC-7, [email protected] wrote: >> >> A few observations on the proposal (especially when seen from the C++ >> side) - >> >> 1. When client receive a RST_STREAM, a GOAWAY, deadline expires, the >> connection breaks or any similar error condition - >> - A fake status message is generated. The status_details reflect >> the error with which the RPC failed. >> - The documentation should be changed accordingly, or made less >> stringent that the trailers are what were actually received from the >> wire. >> >> Updated comments to stop suggesting that trailer is always from the network. > >> 1. C++ allows the server to cancel. It differs from the other >> platforms on this and it probably shouldn't be able to do this, but it is >> the current ground truth, which means the server can also log >> EVENT_CANCEL. >> - This is fine, since the current documentation does not disallow >> the server to log EVENT_CANCEL. >> >> Note however that EVENT_CANCEL's meaning on server side would continue to mean that a cancellation has already happened. Presumably even after a server initiated cancellation in C, the server application will still get some signal that the call has been cancelled. Updated comment to clarify this. > >> 1. The client can initiate a Cancel but still receive the status from >> the server before the Cancel actually takes affect. >> - In this case, implementations should log the server trailers >> since that is how the RPC actually ended. >> >> According to the (yet to be merged) gRPC call semantics <https://github.com/grpc/grpc/pull/15460/files>, when a CANCEL happens: "inbound and outbound buffered data should be cleared. Cancellation trumps graceful completion; if the client gRPC implementation received the Trailers before the cancellation, yet the client application has not received the Trailers, then cancellation generally should win." I agree that if the implementation sees trailers it is fine to log them, but the implementation is not required to use the received status to end the RPC. > >> - >> - Since this is inherently racy, it should be fine for tools to be >> slightly imprecise. >> >> Agreed. -- Spencer Fang -- 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/CAK%3D-x_6JpNMH5j4MwrTyZxzW9uiVfVOjgqFCEYPSQLFEcSfBpw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
