Skip to content
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

Reduce request timeout to 10s from 60s #876

Merged
merged 2 commits into from
Oct 8, 2019

Conversation

kirankumarkolli
Copy link
Member

This value is used to denote the maximum timeout per network request, rather than the overall request. Cosmos SDK's availability resiliency is heavily reliant on failure detection and retries, both within a partition as well as between regions. However, this requires us to not wait indefinitely (which, honestly, 60 seconds is) for a response from the server, and timeout such network calls and let our retry logic kick in.

Hence.. this change decreases the timeout from 60s to 10s.

@bartelink
Copy link
Contributor

bartelink commented Oct 7, 2019

Is there/will there be/would you recommend an equivalent adjustment for v2?

@kirankumarkolli
Copy link
Member Author

@bartelink yes there is a V2 follow-up in-flight.

@kirankumarkolli kirankumarkolli merged commit d385b28 into master Oct 8, 2019
@kirankumarkolli kirankumarkolli deleted the users/kirankk/connection_timeout branch October 8, 2019 14:15
@rmandvikar
Copy link

rmandvikar commented Dec 10, 2020

@kirankumarkolli

the default value of ConnectionPolicy.RequestTimeout is surfaced (used) as default value for CosmosClientOptions.RequestTimeout. i'm seeing the doc is not updated (default still says 60s instead of 10s). could someone please update that?

see https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.cosmos.cosmosclientoptions.requesttimeout?view=azure-dotnet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants