Network retries or time outs

[kraghu]

Please answer these questions before submitting your issue.

What version of gRPC are you using?

1.4.0 on Android

What JVM are you using (java -version)?

1.8

What did you do?

I am trying to add a retry policy. It seems grpc after network failure doesn't re-connect immidiately even when network is back.

If possible, provide a recipe for reproducing the error.

• disable network n keep on aeroplane mode
• try to run the app
• enable back network

You will see grpc doesn't connect back even when you retry so many times. it takes for 25-30 secs to retry again.

What did you expect to see?

grpc should connect immediately on network availability. I like to know the right amount of time for waiting .

What did you see instead?

it never connects back

Is there a way to configure the retries ? or to get to know the retry connection time ?

[ericgribkoff]

Thanks for filing this. This is a known issue, but it looks like it doesn't have have a previously tracked issue on Github: gRPC's default name resolver will attempt to re-resolve the hostname the network is down at 60 second intervals. If the network is restored immediately after a failed name resolution attempt, it can take up to 60 seconds for gRPC to attempt to resolve the hostname and the channel to become usable.

The proper fix for this is to implement an Android-specific name resolver that avoids the 60-second timer and receives notice from the OS when the network is back up. This work is in-progress: I'll update this thread once a PR is ready (should be sometime early next week).

You will see grpc doesn't connect back even when you retry so many times. it takes for 25-30 secs to retry again.

The UNAVAILABLE responses you see here are actually cached by the gRPC channel, so the number of times you retry doesn't effect things. One workaround that might help in the meantime is enabling wait-for-ready on the call options: this will cause the RPC to wait for the network to become available, rather than failing immediately. It doesn't avoid the <60 second wait time, but it does avoid having to keep retrying in a loop until the timer goes off.

[kraghu]

Thanks @ericgribkoff for the quick response. I will wait for this PR .

[ericgribkoff]

Ooops, sorry about the incorrect assigning of this issue. Re-assigned to me, will update when it's ready.

[ejona86]

Related: #2169

[ejona86]

Closing, since this is being handled as part of #2169 (which added an API in 1.8 that should address this) and #3685 (to reduce the impact when not using the new API)