On Wed, Mar 1, 2017 at 10:20 AM, 'Eric Anderson' via grpc.io < grpc-io@googlegroups.com> wrote:
> On Mon, Feb 27, 2017 at 8:53 AM, 'Mark D. Roth' via grpc.io < > grpc-io@googlegroups.com> wrote: > >> While talking with Craig on Friday, we realized that we need to make the >> wire protocol a bit stricter in order to implement retries. >> >> Currently, the spec allows status to be sent either as part of initial >> metadata or trailing metadata. >> > > Currently the spec doesn't say when it is appropriate. This is because the > spec is only on the HTTP/2 level and doesn't actually define gRPC semantics. > > I think you mean HTTP headers and trailers instead of using the term > "metadata." gRPC always has trailing metadata, but may not have initial > metadata. Status must come on the trailing metadata. In HTTP parlance, it > may come in the initial headers only when those initial headers are the end > of the response. > > However, as per the When Retries are Valid >> <https://github.com/ncteisen/proposal/blob/75e08fa10405430e8177cfd91bf63a25ff4ad617/A6.md#when-retries-are-valid> >> section >> of the gRFC, an RFC becomes committed when "the client receives a non-error >> response (either an explicit OK status or any response message) from the >> server". >> > > Just to be clear, the only time "an explicit OK status" would matter is > with a streaming call. In a unary call the OK status will always be after > the response message. > > >> This means that in a case where the server sends a retryable status, if >> the status is not included in the initial metadata, the client will >> consider the RPC committed as soon as it receives the initial metadata, >> even if the only thing sent after that is the trailing metadata that >> includes the status. >> > > What? That does not seem to be a proper understanding of the text, or the > text is wrongly worded. Why would the RPC be "committed as soon as it > receives the initial metadata"? That isn't in the text... In your example > it seems it would be committed at "the trailing metadata that includes a > status" as long as that status was OK, as per the "an explicit OK status" > in the text. > The language in the above quote is probably not as specific as it should be, at least with respect to the wire protocol. The intent here is that the RPC should be considered committed when it receives either initial metadata or a payload message. It is necessary that receiving initial metadata commits the RPC, because we need to report the initial metadata to the caller when it arrives. If we retry after that and get a different set of metadata, then we are giving the application an inconsistent view of the result. Noah, we should probably clarify the wording here. > > > Thus, we need to require that whenever the server sends status without >> sending any messages, the server should include the status in the initial >> metadata (and then close the stream without bothering to send trailing >> metadata) instead of sending both initial metadata and then trailing >> metadata. >> > > This is generally good practice assuming you mean "headers" instead of > "metadata". But I don't see any argument here for requiring it and I don't > see any impact to retry. > > Since an application can force initial headers to be sent (at least in > Java), this can't really be a strong requirement. Java does do this > generally though, as was required for our Auth support and similar > conversion of gRPC status codes to HTTP status codes. > I think it's fine for the server application to force initial metadata to be sent. It's just that once the client sees that metadata, it will consider the RPC to be committed, and no retry will be attempted even if the request subsequently fails. > > Based on a previously encounted interop problem (see >> https://github.com/markdroth/grpc/pull/3, which was included in >> https://github.com/grpc/grpc/pull/7201), I believe that grpc-go already >> does the right thing here (although Saila and Menghan should confirm >> that). However, since that previously encountered problem did not show up >> with Java or C++, I suspect that those stacks do not do the right thing >> here. >> > > If my correction of the nomenclature is correct, then Java already does > this for the most part. This isn't something that can be enforced in Java. > But the normal stub delays sending the initial metadata until the first > response message > <https://github.com/grpc/grpc-java/blob/master/stub/src/main/java/io/grpc/stub/ServerCalls.java#L281>. > If the call is completed without any message, then only trailing metadata > is sent. > Interesting. If that's the case, then why did that interop test only fail with Go, not with Java? > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to grpc-io@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/CA%2B4M1oM3EeiLrbDUCkpafUZV7%3DBXN6KRp%3DJ6z8Q-OtYqCmpKCQ% > 40mail.gmail.com > <https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oM3EeiLrbDUCkpafUZV7%3DBXN6KRp%3DJ6z8Q-OtYqCmpKCQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Mark D. Roth <r...@google.com> 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@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/CAJgPXp5cxvysjmvnNHNU%3De34bJGo-Ltqx0AYFLJPPr%3DF49iDEA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
