Don't see a way to know the current state of a client connection (connected or not) about grpc-go HOT 6 CLOSED

I can add a getter for the state of ClientConn. But be aware of that this kind of getter is always racy -- you could get stale state (the underlying could change the state at any time.) when you call that getter. That's the reason I did not add that in the first place. Actually, you can feel free to send requests when the connection is doing retries unless you inject too many pending requests leading to memory issues.

from grpc-go.

I don't think we should be adding APIs that are fundamentally racy. And a network connection can fail at any time, so it's not just a startup problem.

If an RPC service needs a way to probe the liveness of a connection, it can easily add a Ping method or similar.

from grpc-go.

Actually I did realize that I would need this also after the connection has
been established. The problem of just sending requests when the connection
is down is that I do have a ton of those and some of those are long
running. I have no problem returning an error or losing requests (this is
for a sharded pubsub) but I can't keep clients pending if one of the nodes
is not responding.

I am going to do some experiments with timeouts and see where I get.

On Tue, Mar 17, 2015 at 6:45 PM, David Symonds [email protected]
wrote:

I don't think we should be adding APIs that are fundamentally racy. And a
network connection can fail at any time, so it's not just a startup problem.

If an RPC service needs a way to probe the liveness of a connection, it
can easily add a Ping method or similar.

—
Reply to this email directly or view it on GitHub
#121 (comment).

from grpc-go.

So, what about having the option to define a callback triggered when the connection status changes ?

from grpc-go.

That's just as racy, and a lot of the time there's no way to tell that the connection is broken until you try to use it.

from grpc-go.

regarding callback approach,
i) As dsymonds mentioned, it is still racy unless the calls holds a lock (so that others cannot change the state) when it runs, which is clearly not a sound solution;
ii) I always try hard to avoid all these callback based stuffs in grpc-go lib and favor the simple synchronous model which has been used in it.

from grpc-go.