Skip to content

Do not retry when timeout is hit #1093

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

Merged
merged 1 commit into from
Dec 5, 2014
Merged

Do not retry when timeout is hit #1093

merged 1 commit into from
Dec 5, 2014

Conversation

Mpdreamz
Copy link
Member

@Mpdreamz Mpdreamz commented Dec 5, 2014

this PR adds a safeguard for retrying after the timeout is hit as reported on #1080 .

This prevents:

  • a query that took 60seconds on one node to be retried on a second node.
  • a query that timed out after 30seconds on 2 nodes to be retried a third time.

By default this listens to SetTimeout() which itself defaults to 60 seconds. The max retry timeout can be configured separately by calling SetMaxRetryTimeout().

The MaxRetryException message itself clearly reflects when its thrown because we exceeded the MaxRetryTimeout.

@gmarz
Copy link
Contributor

gmarz commented Dec 5, 2014

LGTM

gmarz added a commit that referenced this pull request Dec 5, 2014
@gmarz gmarz merged commit 850b1a4 into develop Dec 5, 2014
@gmarz gmarz deleted the fix/max-retry-timeout branch December 5, 2014 23:39
@ankitkinra
Copy link

I want confirm behavior of SetTimeout() from pre 1.3 version to 1.3 version. Say we have the following code in Nest Api 1.0

var timeoutInMillis = 100;
var maxRetries = 3;
var config= new ConnectionSettings(pool);
config.SetTimeout(timeoutInMillis);
config.MaximumRetries(maxRetries);

Now imagine the scenario where request times out on the first node in 100 milliseconds, the request will repeat for 3 more times with each timeout being 100 milliseconds, when the same code is migrated to Nest 1.3.1 with the above fix, the request will only be tried for 100 milliseconds and will not be retried as by default MaxRetryTimeout will be equal to Timeout, hence this becomes a breaking change.
I wonder if the default value of MaxRetryTimeout could have been maxRetries * timeoutInMillis

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.

3 participants