examples: Replace context.Background with context.WithTimeout

[menghanl]

example clean up after #1854

[vitalyisaev2]

I would just like to mention that for streams simple cancellation (context.WithCancel instead of context.WithTimeout) could be a little bit more idiomatic. Steams may be potentially infinite, so timeouting on working stream may cause data inconsistency and so on.

[menghanl]

@vitalyisaev2 Thanks for taking a look!
That's a good point. I have updated the code accordingly. PTAL.

[vitalyisaev2]

This patch is fully in line with streaming protocol changes proposed in #1854, LGTM.

[dfawley]

I would just like to mention that for streams simple cancellation (context.WithCancel instead of
context.WithTimeout) could be a little bit more idiomatic. Steams may be potentially infinite, so
timeouting on working stream may cause data inconsistency and so on.

I disagree; even streaming RPCs should always have deadlines set. One problem that could occur without a deadline is that if the RPC is wait-for-ready, it will block indefinitely if all servers are down. Since your stream can't be expected to live forever (due to inevitable connection errors), if you want it to be persistent, you'll need to have code to recreate it when it fails. This same code can recreate it when the deadline is reached as well.

[vitalyisaev2]

@dfawley Unfortunately I'm not aware of 'wait-for-ready` RPC semantics... But I think we can consider simple and wide-spread examples of streaming.

For instance, suggest we've implemented file upload / download protocol on the top of the GRPC stream (so it would be client-side streaming for uploading and server-side streaming for downloading). We have to download a huge 10GB file, but we have weak connection with low throughput. If we set a timeout for this kind of stream, we'll never be able to download the file, because the stream will be canceled and next time download will start from the very beginning.

Another example is a gossip protocol utilizing GRPC bidirectional streaming. From my point of view, this stream should not be terminated by timeout either. Because data exchange between peers should take place during the whole lifetime of peer processes. I agree with you that reconnection and retrial logic should be implemented in any case, but I don't see a good reason to terminate the stream which is actually expected to live forever.

[dfawley]

@vitalyisaev2,

Unfortunately I'm not aware of 'wait-for-ready` RPC semantics

There are other ways an RPC can get stuck without a deadline. If the resolver never resolves the target name when the client is created, even fail-fast (non-wait-for-ready) RPCs will block indefinitely. In general, it's a bad idea to perform unbounded, blocking operations. If you have other things in place to prevent it from blocking forever (like SIGINTing the whole process), then I guess it should be OK. But I'd prefer for our "official" examples of streaming RPCs to use a timeout.

the stream will be canceled and next time download will start from the very beginning.

This may be a problem with the API design; if you're transmitting large files over an unreliable network, you should ideally be able to resume them from the middle after reconnecting.