Expose option to eagerly create connection

[carl-mastrangelo]

There doesn't seem to be a way to eagerly connect to a target address. My use case:

1. Create gRPC ClientConn
2. Do some work
3. Try to send an RPC using results from 2
4. RPC fails because the address is from 1 is wrong.

gRPC Java exposes this through the channel state API, but for Go I expect this to be a DialOption.

[lyuxuan]

Use grpc.WithBlock() to block until a connection is established.

[dfawley]

You also will want to use grpc.FailOnNonTempDialError(true) so you don't wait until the context expires to determine there was a persistent connection error.

Similar to Java, Go also have a connectivity state API:

https://godoc.org/google.golang.org/grpc#ClientConn.GetState
https://godoc.org/google.golang.org/grpc#ClientConn.WaitForStateChange

[carl-mastrangelo]

@dfawley I looked at those, but neither say that they have any effects. GetState doesn't say that the state will ever go towards READY. WaitForStateChange doesn't imply it kick the ClientConn towards READY, only that if it does change, it will eventually run. Neither move the ClientConn towards the state I want.

@lyuxuan Thanks! it would be very helpful if WithBlock had some synonyms in that doc. I ctrl-F'd through the doc for "Eager" and "ready", but neither came up.

[dfawley]

@carl-mastrangelo Go doesn't currently have the concept of idleness - it starts in Connecting, so these functions don't have side-effects.

[carl-mastrangelo]

@dfawley Then how does pick first work? Doesn't that LB policy imply that connections are lazily created?

[dfawley]

The balancer doesn't matter - all ClientConns always start in Connecting. The resolver returns addresses, the balancer gets them and then it immediately tries to connect to the ones that will be used. Nothing in this process waits for an RPC. We also eagerly reconnect, even after a GOAWAY, which is a known, meaningful difference between Go & other languages. #1786

[carl-mastrangelo]

Ok so what you are saying is Dial and DialContext are always eager. WithBlock still doesn't seem to be what I want because:

... blocks until the underlying connection is up

Which connection is this? In the load balanced case there may be multiple. Does it wait until failure, or success, or either?

#1786

It would be great if this could be prioritized. It was confusing to me that Dial would return an error type, but not block. I think NewClient could return an $CLIENT, without an error param, making it clear that no connection has been established.

[dfawley]

@carl-mastrangelo WithBlock blocks until the ClientConn is Ready, which is whenever the LB policy decides, but that's typically when a single connection itself becomes Ready. It blocks until the deadline is reached, or until there is a non-termporary error if you also use FailOnNonTempDialError.

If you don't want to block, you can use the connectivity state API instead.

It would be great if this could be prioritized.

I agree, but we have a few things in front of it right now. It will probably be a couple more quarters before it happens at this rate, assuming no new things come in.

[dfawley]

We always eagerly create the connection. When we support NewClient, we will update the connectivity state API to allow for this (#1786).