Skip to content

Storage: Add Truncated exponential backoff for connection reset #5

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

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

sangramql
Copy link
Owner

Issue [5879]
Cloud Functions & Storage: fails intermittently with ProtocolError + ConnectionResetError

@sangramql
Copy link
Owner Author

@mf2199 please review

for retry in range(self.retries):
try:
time.sleep(min(random.random() + 2 ** (retry - 1), 32))
api_response = client._connection.api_request(
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need a random number here? Why can it not be a fixed number, say, 1? Also, consider an extreme case when random.randon() == retry == 0. Then there will be no backoff whatsoever.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need a random number here? Why can it not be a fixed number, say, 1?

Random number of milliseconds less than or equal to 1000. This helps to avoid cases where many clients get synchronized by some situation and all retry at once, sending requests in synchronized waves. The value of random_number_milliseconds is recalculated after each retry request.

Also, consider an extreme case when random.randon() == retry == 0. Then there will be no backoff whatsoever.

The wait time is min((random_number_milliseconds + (2^n)), maximum_backoff), with n incremented by 1 for each iteration (request).
So if random == retry == 0, there would be 1 secs delay, since 2**0 = 1

@mf2199
Copy link

mf2199 commented Jul 14, 2019

There are no tests for the added code which will reduce the coverage.

@sangramql
Copy link
Owner Author

There are no tests for the added code which will reduce the coverage.

Will be adding tests once approach and implementation is confirmed.
Thank you for prompt review Maxim.

@mf2199
Copy link

mf2199 commented Jul 15, 2019

The approach should be fine as long as it's properly tested.

@sangramql
Copy link
Owner Author

The approach should be fine as long as it's properly tested.

Ok, I'll add the tests.

@sangramql
Copy link
Owner Author

@ mf2199 please review the code. Unit tested.
Moved the retry logic to bucket.py, since there were other dependencies failure in _helpers.py.

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.

2 participants