Skip to content

Add backoff to stream reconnect #62

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 2 commits into from
Nov 3, 2016
Merged

Add backoff to stream reconnect #62

merged 2 commits into from
Nov 3, 2016

Conversation

drichelson
Copy link
Contributor

@drichelson drichelson commented Nov 2, 2016

Initial changes to initialization. This attempts to address the fact that we aggressively retry streaming connections. There are other improvements to make, but this one is bite-sized and has other corrections as well.

We're also now properly reporting that the client is initialized or not.

@@ -35,8 +35,8 @@ class Config(object):
def __init__(self,
base_uri='https://app.launchdarkly.com',
events_uri='https://events.launchdarkly.com',
connect_timeout=2,
read_timeout=10,
connect_timeout=10,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

These were lower than what we've seen in the field (5 seconds just for dns lookup) so I'm upping them here.

@@ -149,10 +149,11 @@ def __init__(self, sdk_key, config=None, start_wait=5):
log.info("Waiting up to " + str(start_wait) + " seconds for LaunchDarkly client to initialize...")
update_processor_ready.wait(start_wait)

if self._update_processor.initialized:
if self._update_processor.initialized() is True:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was not evaluating correctly.. it would indicate success even when the streaming processor had not been initialized.

self._ready.set()
except HTTPError as e:
if e.response is not None and e.response.status_code is not None:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We now stop the reconnect loop if a 4xx response code is seen.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

which begs the question- is it possible for a 404 error to be transient? due to a misconfigured/misbehaving CDN?

@drichelson drichelson changed the title Initial changes to initialization [HOLD] Initial changes to initialization Nov 2, 2016
@drichelson drichelson changed the title [HOLD] Initial changes to initialization Add backoff to stream reconnect Nov 2, 2016
@pkaeding
Copy link
Contributor

pkaeding commented Nov 3, 2016

This definitely looks good. It might also be worth not retrying at all when we get a status in the 4xx range, since retrying the same request should result in the same status.

@drichelson drichelson merged commit 44573be into master Nov 3, 2016
@drichelson drichelson deleted the dr/initImprovements branch November 3, 2016 22:05
eli-darkly added a commit that referenced this pull request Jun 19, 2018
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