Responses inline On Thursday, December 13, 2018 at 7:06:13 AM UTC-8, for.sh...@gmail.com wrote: > > Hi All > > I have a question about the bidirectional stub. I'm using gRPC-java 1.16.1. > > If the server side call onCompleted or onError. Does it mean the stub has > already been closed or just the server side been closed? >
>From the point of view of the server, it is closed. There is a delay propagating it to the client, but it no longer useable by the server. > This can become to another question. Once the server invoked onError, the > client side needs to call onComplete/onError to close its stream? > No, the client will tear down the stream. The reason is that the server send the "Status" in the trailing Metadata, which terminates the RPC. > > I wrote a simple echo service to verify this question. > At first, when the server invoked onError to tell the client. The client > invoked onCompleted to tell the server that the client stream is completed. > However I found the onCompleted method in the server observer did not be > invoked. So is it indispensable? Does it cause any connection leak? > onCompleted (from the servers point of view) means "I'm done with this, please clean things up". There may have been messages en route from the client to the server when the server calls onCompleted. The server already indicates that it doesn't want anything more to do with that RPC. > > I'm confused by the gRPC guideline concepts. > > RPC termination > > In gRPC, both the client and server make independent and local > determinations of the success of the call, and their conclusions may not > match. This means that, for example, you could have an RPC that finishes > successfully on the server side (“I have sent all my responses!”) but fails > on the client side (“The responses arrived after my deadline!”). It’s also > possible for a server to decide to complete before a client has sent all > its requests. > Consider an RPC with a deadline of 5 seconds, and a network delay of 1 second. The following timeline explains how this can happen: t0.0s: Client starts an RPC with deadline 5 seconds t1.0s: Server Receives RPC, sees a deadline of 5 seconds t4.9s: Server finishes the RPC after 3.9s, and Sends the RPC, thinking it has succeeded t5.0s: Client deadline is reached, the RPC is cancelled. t5.9s: Client gets the server message, for an already failed RPC. This is discarded. t6.0s: Server gets notice of the Client cancellation, for an already successful RPC. This is discarded. Both endpoints have to discard any extra messages and headers after they complete the RPC, or else they would have to keep RPC state around in memory for ever. Suppose the server never responded at all. The client would have to hold on the the status of the RPC forever, not knowing that the server is gone. > > Thanks > > Shin > -- 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/94c0f9bd-26c4-4486-9d62-4e89e11ad77d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
