The bidirectional stub life cycle

[for.sh...@gmail.com]

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?

This can become to another question. Once the server invoked onError, the client side needs to call onComplete/onError to close its stream?

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?

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.

Thanks

Shin

[Carl Mastrangelo]

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