-
-
Notifications
You must be signed in to change notification settings - Fork 92
When connection queue is full, respond with a 503 error. #745
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
base: main
Are you sure you want to change the base?
Conversation
β 21 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
05f2bee
to
57206a1
Compare
ead7721
to
97a6317
Compare
So now it ... fails, but not as consistently? I don't really know. |
Any other thoughts? It's pretty annoying that it passes some of the time but not all the time. |
45698b9
to
4a5abc5
Compare
Looks like we're down to only 3.14 failing, which were already failing on |
|
||
def test_overload_results_in_suitable_http_error(request): | ||
"""A server that can't keep up with requests returns a 503 HTTP error.""" | ||
localhost = '127.0.0.1' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be possible to import a constant with this from somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't find it.
def serve(self): | ||
"""Serve requests, after invoking :func:`prepare()`.""" | ||
threading.Thread(target=self._serve_unservicable).start() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to wait for the thread to complete somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... Probably not? other way around, it's possible it should be a daemon thread if you don't want sending 503s to delay shutdown of a process.
def _serve_unservicable(self): | ||
"""Serve connections we can't handle a 503.""" | ||
while self.ready: | ||
conn = self._unservicable_conns.get() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need a timeout?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming stop() is always used, then no.
while self.ready: | ||
conn = self._unservicable_conns.get() | ||
if conn is None: | ||
return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should call shutdown()
here (under Python 3.13+).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you clarify what you mean?
cheroot/server.py
Outdated
level=logging.ERROR, | ||
traceback=True, | ||
) | ||
conn.linger = True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just copying existing code that did that in error handling, but empirically looks like not on Linux at least. Will see what CI does on Windows and macOS.
request = HTTPRequest(self, conn) | ||
try: | ||
request.simple_response('503 Service Unavailable') | ||
except Exception as ex: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to make this only intercept narrow exceptions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a catchall so the thread doesn't die. But I can make more likely exceptions not get logged, at least.
The 503 responses are run in a thread
c532189
to
b460ce4
Compare
Failures are due to 3.14 and #747, unrelated to this PR as far as I can tell. |
β What kind of change does this PR introduce?
β What is the current behavior? (You can also link to an open issue here)
When connections can't be handled, the connection is just closed.
β What is the new behavior (if this is a feature change)?
A 503 error is returned, as suggested in TODO comment in relevant part of the code.
Since writing to the socket is blocking, this is done in a thread.
π Other information:
For some reason OpenStack Ironic needs this apparently, I didn't dig into why.
π Contribution checklist:
(If you're a first-timer, check out
this guide on making great pull requests)
the changes have been approved
and description in grammatically correct, complete sentences
This change isβ