Does DialContext (in golang impl) do retries when it fails to establish connection on the first time?

[BDani]

I could not find anything mentioned regarding dialing and reconnects.
https://pkg.go.dev/google.golang.org/grpc#DialContext

[Amit Saha]

Retry support is enabled by default, you can disable it using the https://pkg.go.dev/google.golang.org/grpc#WithDisableRetry DialOption. However, note that this doesn't mean that the client will not return until a connection has been established. Hence, you will have to combine it with WithBlock DialOption https://pkg.go.dev/google.golang.org/grpc#WithBlock DialOption - which ensures that the DialiContext() function will not return till the connection

has been established.

A good practice I believe is to combine a context with timeout along with the WithBlock DialOption to ensure that you get the behaviour where your client say will wait unto 30 seconds to establish a connection, otherwise, it will exit. A function like this can help:

https://github.com/practicalgo/code/blob/1cc0062716cf31c103731f4c32716649b21cb67e/chap10/client-resiliency/client/main.go#L16

(The above example is a code snippet from my book)

Also worth referring to is the WaitForReady call option (https://pkg.go.dev/google.golang.org/grpc#WaitForReady) which when combined with the default retry behaviour will by default wait for the underlying connection to be available (set up) and not simply bail out if for example, server is still starting up.

[BDani]

Thank you for your answer, that clarified things. One more question, there is the two DialContext approaches, one with WithBlock, the other without it. So the thing I am most confused about, if I am using the non-blocking variant, without WithBlock, then what will the timeout set for the context affect? It is not entirely clear to me based on the documentation. Will it still use this timeout, when let's say, we are making a grpc call, with a not yet established connection. Will this grpc call return after timeout with an error, since it is waiting for the connection to be established? Also, if the connection IS established, if the grpc call would take a long time for the data to go through, would the timeout still be applied for the call even if the connection is established?

[Amit Saha]

On Thu, Jul 7, 2022 at 7:16 PM BDani <dan...@alpaca.markets> wrote:

Thank you for your answer, that clarified things. One more question, there is the two DialContext approaches, one with WithBlock, the other without it. So the thing I am most confused about, if I am using the non-blocking variant, without WithBlock, then what will the timeout set for the context affect?

Good question -  I don't recall experimenting with this or I have forgotten. Perhaps you could give it a go and see what happens? You may find turning on additional logging useful on the server side as well as client side: https://pkg.go.dev/google.golang.org/grpc#readme-how-to-turn-on-logging

 

It is not entirely clear to me based on the documentation. Will it still use this timeout, when let's say, we are making a grpc call, with a not yet established connection. Will this grpc call return after timeout with an error, since it is waiting for the connection to be established? Also, if the connection IS established, if the grpc call would take a long time for the data to go through, would the timeout still be applied for the call even if the connection is established?

If the underlying channel is not connected, during a gRPC method call, an attempt will be made to re-establish a connection and I am guessing the DialContext() options will play a role there again. For gRPC method calls when the channel has been established, you can set timeouts on the client side via the Context - the first argument. As far as my understanding is, the Context specified to DialContext() doesn't enforce timeout on the gRPC method calls other than when establishing the connection, if the connection hasn't been established. To summarize my current

understanding:

Channel not established -> DialContext timeout -> gRPC method call context timeout

Channel established -> gRPC method call context timeout

On Thursday, July 7, 2022 at 3:29:55 AM UTC+2 amits...@gmail.com wrote:

Retry support is enabled by default, you can disable it using the https://pkg.go.dev/google.golang.org/grpc#WithDisableRetry DialOption. However, note that this doesn't mean that the client will not return until a connection has been established. Hence, you will have to combine it with WithBlock DialOption https://pkg.go.dev/google.golang.org/grpc#WithBlock DialOption - which ensures that the DialiContext() function will not return till the connection

has been established.

A good practice I believe is to combine a context with timeout along with the WithBlock DialOption to ensure that you get the behaviour where your client say will wait unto 30 seconds to establish a connection, otherwise, it will exit. A function like this can help:

https://github.com/practicalgo/code/blob/1cc0062716cf31c103731f4c32716649b21cb67e/chap10/client-resiliency/client/main.go#L16

(The above example is a code snippet from my book)

Also worth referring to is the WaitForReady call option (https://pkg.go.dev/google.golang.org/grpc#WaitForReady) which when combined with the default retry behaviour will by default wait for the underlying connection to be available (set up) and not simply bail out if for example, server is still starting up.

On Thursday, July 7, 2022 at 2:22:25 AM UTC+10 BDani wrote:

I could not find anything mentioned regarding dialing and reconnects.
https://pkg.go.dev/google.golang.org/grpc#DialContext

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/Ruk2VtfoXlU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/62f61522-fa4c-4f09-81ed-c28ad6e23e1bn%40googlegroups.com.

[BDani]

right makes sense, thank you, especially, since you pass a context on gRPC calls as well, which I forgot about. Thanks.