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

Runaway loop, never returns #16

Closed
bcoover opened this issue Aug 28, 2016 · 2 comments
Closed

Runaway loop, never returns #16

bcoover opened this issue Aug 28, 2016 · 2 comments

Comments

@bcoover
Copy link

bcoover commented Aug 28, 2016

I have an Exchange server with misconfigured autodiscover (doesn't return a good response), and your autodiscover never returns, it just runs forever (see more below)... I have been writing Exchange code for Python for a couple of years, and I'd be happy to join your project and then I could fix issues like this.

I found the issue in your code:
util.py line 253

You are using a "while True:" loop, which is dangerous in Python, I had some similar issues with my project. I recommend you put in some type of limit like:

max_loops = 10
i = 0
while i < max_loops:
    i += 1
    # do stuff
@ecederstrand
Copy link
Owner

Thanks for your comments! The loop in post_ratelimited() actually does have a safeguard; have a look at the max_wait and max_redirects values. If those two don't cover all possible paths in the code, please let me know.

What you're probably seeing is an artifact of the very large max_wait value. If a request fails, the loop will wait for increasing amounts of time, up to 1 hour, before bailing. The reason for this is that in my experience servers often malfunction for short periods of time, either because of migrations, maintenance tasks, misconfigurations or heavy load, or because the connecting user has hit a throttling policy limit.

If the loop exited early, consumers of exchangelib that don't implement their own rate-limiting code could quickly swamp such a server with new requests. That would only make things worse. Instead, it's better if the request loop waits patiently until the server is functioning again.

If the connecting user has hit a throttling policy, then the server will only respond with a HTTP 401, as if the password is wrong. The only cure is to stop making requests. There is no other indication AFAIK, so the code can't distinguish between the two situations.

Anyway, I'd be happy for any contributions to the project!

@ecederstrand
Copy link
Owner

Please re-open if you still think this is a bug.

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