-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connection backoff with limited retries hangs indefinitely #1586
Comments
It sounds like the right solution here would be a mode on the connection pool to allow it to avoid eagerly reconnecting if there are no outstanding requests. That would allow you to configure a short backoff (and short wait time) without imposing a retry limit. Would that work for your use case? |
Yes, that should work! |
Thinking about this more, the current behavior seems potentially problematic even in the common case of iOS apps that use gRPC with changing network conditions. Consider the following scenario:
When the user comes back (minutes to hours later), wouldn't they have to wait up to 2 minutes (default max backoff) for the app to be usable again because of the backoff logic? |
Describe the bug
For local use, I'm trying to configure the Swift gRPC client's connection backoff so that it:
The issue is that once ConnectionBackoffIterator reaches the retry limit, the pool never schedules another connection attempt — all future RPCs fail after maxWaitTime. So effectively, once there has been a connection failure, the GRPCChannelPool (or ClientConnection) becomes unusable. It also doesn't propagate the connection error until maxWaitTime is reached, even if retries are exhausted before that.
RPCs fail with this error:
Allowing unlimited retries fixes the issue of the pool becoming unusable, but that's not a viable solution because the pool doesn't seem to stop retrying even after all RPCs have timed out. The server could be stopped and may not be started again for hours or days, and my quick-retry requirement means that the app will be wasting a lot of CPU trying to connect in the background.
Some RPCs could take a very long time when there are no connection issues, so I can't set a short timeLimit on CallOptions.
I wouldn't mind doing the retry logic myself (even if temporarily) if the gRPC behavior won't work for my needs, but the same occurs with ClientConnection and
connectionBackoff = nil
, and GRPCChannelPool doesn't seem to support completely bypassing the backoff logic.grpc-swift version: 1.14.2
Debug build
Platform: macOS 13
To reproduce
Or with the old ClientConnection API:
I've tried various combinations of
retries
,minimumConnectionTimeout
,maxWaitTime
, andcallStartBehavior
to no avail.Expected behaviour
Describe what you expect to happen when the steps above are followed.
Additional information
Logs with retry limit = 1:
The text was updated successfully, but these errors were encountered: