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

CloudDNS timeout checks status too fast #52

Closed
scottgilbert opened this issue Apr 4, 2013 · 2 comments
Closed

CloudDNS timeout checks status too fast #52

scottgilbert opened this issue Apr 4, 2013 · 2 comments

Comments

@scottgilbert
Copy link

The CloudDNS "check for timeout" code, checks the status of a request too fast, which causes API rate limiting to be imposed and the pyrax call to fail - even though the requested operation eventually succeeds.

I believe the key lies in clouddns.py, within the _async_call() function, which contains this code:

while (ret_body["status"] == "RUNNING") and not timed_out:
            _resp, ret_body = self.api.method_get(massagedURL)
            if self._timeout:
                timed_out = ((time.time() - start) > self._timeout)

That "while loop" will fetch the status URL as fast as possible.

I've found that the status rate-limit on my account is 5/sec. When this code is executed on a server with sufficiently fast network connectivity to the API endpoints, this rate-limit is encountered every time.

May I suggest that a brief time delay be added into the "while loop"? Perhaps 0.5 seconds? Perhaps this delay could also be exposed as a configurable option?

@EdLeafe
Copy link
Contributor

EdLeafe commented Apr 4, 2013

Good idea. I will add that in the next release.

@scottgilbert
Copy link
Author

Terrific!

I'm very impressed with your quick response and thorough solution to my issue!

Keep up the good work!

Good idea. I will add that in the next release.


Reply to this email directly or view it on GitHub:
#52 (comment)

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

No branches or pull requests

2 participants