On Wed, Mar 1, 2017 at 10:51 AM, 'Mark D. Roth' via grpc.io < [email protected]> wrote:
> On Wed, Mar 1, 2017 at 10:20 AM, 'Eric Anderson' via grpc.io < > [email protected]> wrote: > >> 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. > If initial metadata causes a commit, then the "any response message" will *never* apply, as initial metadata always comes first. So even the corrected intent you propose is questionable since one of the two conditions of "either initial metadata or a payload message" will never occur. Now, maybe the document is wrong or based on false assumptions and needs to be fixed, but the plain reading of text seems the only coherent interpretation at this point. It is necessary that receiving initial metadata commits the RPC, because we > need to report the initial metadata to the caller when it arrives. > That's not strictly true. It could be buffered until it was decided it is a "good" response. Yes, we may not want to do that, but it doesn't seem "necessary" unless it was discussed earlier in the thread. 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? > Very good question. I don't know. I can't read that code well enough to figure out what was actually happening. My naïve reading of the change makes it look like PHP is now processing the initial metadata when previously it wasn't. I don't see anything strange in Java's server that would change the behavior. I had previously thought that Go was the only implementation that always sent initial metadata on server-side. So I'm quite surprised to hear it being the only one that doesn't send initial metadata when unnecessary. -- 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/CA%2B4M1oMXxH55qXb8Mne9mYJgp1L2eF_C29Z%2B6pLT0cB1gxBaHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
