Add possibility to set connect timeout on ManagedChannelBuilder about grpc-java HOT 5 CLOSED

How are you setting it now? What value are you setting it to? What sort of environment are you running in?

However you are doing it now, after Happy Eyeballs the connect timeout (what you want to configure) will probably change. A long time ago there was a goal to have a single timeout for all the parts of the connection establishment (TCP, TLS, HTTP/2). That proved incompatible with multiple other things. Now that we have sticky-TRANSIENT_FAILURE in pick_first and Happy Eyeballs is almost enabled, we may revisit that soon. But I don't know what configuration will be supported.

from grpc-java.

For example for Netty I'm setting it with nettyChannelBuilder.withOption(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000).
Environment is a cloud environment i.e. networking is not an issue.
The problem it solves is that if a client has a long deadline (for e.g. a streaming call) and server is completely down it will wait for the entire long deadline, where clients want to fail fast and abort early (i.e. after connect timeout of 5 seconds).

from grpc-java.

That is only a problem on a new channel, right? (Not to say it isn't a problem, but to confirm that I understand which problem.) Is there only a single server for the channel to connect to, or are there multiple (possibly) available backends?

instead of having to be done in 5 dfferent ways for Netty/shaded Netty/OkHttp/xDs/InProcess

FWIW, xds isn't its own channel type. In-process doesn't have a connect timeout (it fails instantly if server is not bound). OkHttp would be a quite different implementation, as it isn't using an API that can set a connect timeout today.

from grpc-java.

That is only a problem on a new channel, right? (Not to say it isn't a problem, but to confirm that I understand which problem.) Is there only a single server for the channel to connect to, or are there multiple (possibly) available backends?

Correct, only for a new channel. We have setups both with single servers, and multiple servers (one DNS name/multiple IPs).

FWIW, xds isn't its own channel type. In-process doesn't have a connect timeout (it fails instantly if server is not bound). OkHttp would be a quite different implementation, as it isn't using an API that can set a connect timeout today.

Right, I was thinking of XdsServerBuilder which is it's own type.
I wasn't aware that OkHttp was that different; that would make an implementation harder.

Would enabling (aggressive, 10 second) keep-alive solve this? Or is keep-alive only performed after initial connection?
Or failing that, perhaps an interceptor that cancels the call if no headers are received after e.g. 5 seconds.

from grpc-java.

I ended up solving this with an interceptor.

from grpc-java.