Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34k
bpo-35017: Lib/socketserver, do not accept any request after shutdown#9952
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
beledouxdenis commented Oct 18, 2018 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
the-knights-who-say-ni commented Oct 18, 2018
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for your contribution, we look forward to reviewing it! |
43af5d2 to cf649e1CompareMisc/NEWS.d/next/Library/2018-10-19-09-32-07.bpo-35017.vAanVd.rst Outdated Show resolvedHide resolved
Uh oh!
There was an error while loading. Please reload this page.
tirkarthi commented Oct 25, 2018
I think Victor might help here in reviewing this PR. Friendly ping @vstinner |
Uh oh!
There was an error while loading. Please reload this page.
cf649e1 to a9c4abeCompare…ythonGH-9952) Prior to this revision, After the shutdown of a `BaseServer`, the server accepted a last single request if it was sent between the server socket polling and the polling timeout. This can be problematic for instance for a server restart for which you do not want to interrupt the service, by not closing the listening socket during the restart. One request failed because of this behavior. Note that only one request failed, following requests were not accepted, as expected.
a9c4abe to 57f0822Comparebeledouxdenis commented Oct 25, 2018
Thank you very much for your review @vstinner This targets a bug in Python 3.6 and 3.7. Is there something additional to do for this revision to land in these Python releases or will it be back-ported later, potentially through another pull request ? |
tirkarthi commented Oct 25, 2018
@beledouxdenis Once the PR is merged and the reviewer adds "needs backport to 3.7" and "needs backport to 3.6" labels to the PR @miss-islington will cherry pick the commit and create relevant PRs to the branches. If there are any conflicts then you might need to create a PR manually fixing the conflicts during cherry picks. Given the change I think there will be no conflicts. Relevant dev guide section : https://devguide.python.org/committing/?highlight=backport#backporting-changes-to-an-older-version |
beledouxdenis commented Oct 25, 2018
Thank you for the clarification ! |
tirkarthi commented Oct 25, 2018
You're welcome :) I could see only one commit for the PR. In case you have force pushed changes it will make review of the changes between review comments little harder to notice unlike having separate commits. Core devs squash and merge all the commits in a PR as a single commit so for future contributions please push the changes as separate commits for reviews. Thanks |
Uh oh!
There was an error while loading. Please reload this page.
bedevere-bot commented Oct 25, 2018
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
This test can fail on slow buildbots, because it relies on a time condition The unit test can be safely removed, the fix being quite trivial.
The news message now represents what the revision is changing regarding the behavior rather than describing the current unexpected behavior.
Uh oh!
There was an error while loading. Please reload this page.
miss-islington commented Oct 26, 2018
Thanks @beledouxdenis for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 2.7, 3.6, 3.7. |
bedevere-bot commented Oct 26, 2018
GH-10125 is a backport of this pull request to the 3.7 branch. |
…H-9952) Prior to this revision, after the shutdown of a `BaseServer`, the server accepted a last single request if it was sent between the server socket polling and the polling timeout. This can be problematic for instance for a server restart for which you do not want to interrupt the service, by not closing the listening socket during the restart. One request failed because of this behavior. Note that only one request failed, following requests were not accepted, as expected. (cherry picked from commit 10cb376) Co-authored-by: Denis Ledoux <[email protected]>
bedevere-bot commented Oct 26, 2018
GH-10126 is a backport of this pull request to the 3.6 branch. |
miss-islington commented Oct 26, 2018
Sorry, @beledouxdenis and @vstinner, I could not cleanly backport this to |
…H-9952) Prior to this revision, after the shutdown of a `BaseServer`, the server accepted a last single request if it was sent between the server socket polling and the polling timeout. This can be problematic for instance for a server restart for which you do not want to interrupt the service, by not closing the listening socket during the restart. One request failed because of this behavior. Note that only one request failed, following requests were not accepted, as expected. (cherry picked from commit 10cb376) Co-authored-by: Denis Ledoux <[email protected]>
vstinner commented Oct 26, 2018
@beledouxdenis: Hum, the bot failed to create a backport for Python 2.7. Can you please try to do the backport manually? Use "cherry_picker 10cb376 2.7" or "git cherry-pick -x 10cb376". |
beledouxdenis commented Oct 26, 2018
I didn't expect the backport to 2.7, I am not even sure the bug is there. I initially targeted 3.6 and 3.7. Will check anyway if this can be reproduced in 2.7 :). |
Prior to this revision, after the shutdown of a `BaseServer`, the server accepted a last single request if it was sent between the server socket polling and the polling timeout. This can be problematic for instance for a server restart for which you do not want to interrupt the service, by not closing the listening socket during the restart. One request failed because of this behavior. Note that only one request failed, following requests were not accepted, as expected. (cherry picked from commit 10cb376) Co-authored-by: Denis Ledoux <[email protected]>
Prior to this revision, after the shutdown of a `BaseServer`, the server accepted a last single request if it was sent between the server socket polling and the polling timeout. This can be problematic for instance for a server restart for which you do not want to interrupt the service, by not closing the listening socket during the restart. One request failed because of this behavior. Note that only one request failed, following requests were not accepted, as expected. (cherry picked from commit 10cb376) Co-authored-by: Denis Ledoux <[email protected]>
vstinner commented Oct 26, 2018
The code is almost the same, so I'm sure that it has the bug: The fix should be the same :-) |
beledouxdenis commented Oct 26, 2018
I came to the same conclusion. I can re-use my unit test after all :-). |
…H-9952) Prior to this revision, after the shutdown of a `BaseServer`, the server accepted a last single request if it was sent between the server socket polling and the polling timeout. This can be problematic for instance for a server restart for which you do not want to interrupt the service, by not closing the listening socket during the restart. One request failed because of this behavior. Note that only one request failed, following requests were not accepted, as expected. (cherry picked from commit 10cb376)
bedevere-bot commented Oct 26, 2018
GH-10129 is a backport of this pull request to the 2.7 branch. |
GH-10129) Prior to this revision, after the shutdown of a `BaseServer`, the server accepted a last single request if it was sent between the server socket polling and the polling timeout. This can be problematic for instance for a server restart for which you do not want to interrupt the service, by not closing the listening socket during the restart. One request failed because of this behavior. Note that only one request failed, following requests were not accepted, as expected. (cherry picked from commit 10cb376)
The method override `_handle_request_noblock` is there to solve a bug in Python socketserver library which has been solved in - Python 3.6: python/cpython@8b1f52b, - Python 3.7: python/cpython@9080824, through PR python/cpython#9952. These revisions will be included in Python releases 3.6.8 and 3.7.2, and the override will then become useless. We therefore can remove the `_handle_request_noblock` override as soon as the Python 3 releases installed on operating systems supported by Odoo are above - 3.6.8 for Python 3.6 - 3.7.2 for Python 3.7
The method override `_handle_request_noblock` is there to solve a bug in Python socketserver library which has been solved in - Python 3.6: python/cpython@8b1f52b, - Python 3.7: python/cpython@9080824, through PR python/cpython#9952. These revisions will be included in Python releases 3.6.8 and 3.7.2, and the override will then become useless. We therefore can remove the `_handle_request_noblock` override as soon as the Python 3 releases installed on operating systems supported by Odoo are above - 3.6.8 for Python 3.6 - 3.7.2 for Python 3.7 closes#29706
Prior to this revision,
After the shutdown of a
BaseServer,the server accepted a last single request
if it was sent between the server socket polling
and the polling timeout.
This can be problematic for instance
for a server restart
for which you do not want to interrupt the service,
by not closing the listening socket during the restart.
One request failed because of this behavior.
Note that only one request failed,
following requests were not accepted, as expected.
https://bugs.python.org/issue35017
We solved this issue in odoo/odoo by overriding _handle_request_noblock, in the below revision:
odoo/odoo@dcb5641#diff-7c4c00ad10cee1a79d1ed0d8b96f0bfaR140
We would like to avoid having to do so, as this is not a method which is supposed to be overridden.