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

Graceful shutdown can (I think) truncate connections that it shouldn't #1369

Closed
njsmith opened this issue Nov 5, 2016 · 2 comments
Closed
Labels

Comments

@njsmith
Copy link

njsmith commented Nov 5, 2016

The idea of graceful shutdown is that we finish sending out all existing responses before shutting down. But from code inspection, I think it can happen that in certain cases aiohttp will truncate a response, even though it could easily have finished within the time limit.

Specifically, the problem is, how do we know that we've actually finished sending the complete response body to the client? AFAICT there are two ways to do this in asyncio: (a) wait for a connection_lost callback, (b) call await stream_writer.drain(), after calling stream_writer._transport.set_write_buffer_limits(0).

As far as I can tell, aiohttp calls await stream_writer.drain(), but without the crucial second step. Without this, drain can and will return while there is still unsent data buffered inside the event loop, and if we then proceed with shutting down this data can silently lost.

@asvetlov
Copy link
Member

Fixed by #1478
If data has not been sent after lingering timeout -- connection is stalled and should be aborted anyway.

komuw added a commit to komuw/naz that referenced this issue May 31, 2019
What:
- Introduce a configurable timeout when trying to connect to SMSC
- Try and detect when the connection to SMSC is disconnected and attempt to re-connect & re-bind
- bugfix; `asyncio.streams.StreamWriter.drain` should not be called concurrently by multiple coroutines[1]
- when shutting down, `naz` now tries to make sure that write buffers are properly flushed[2][3]

Why:
- Make `naz` more failure tolerant
- Fixes: #67
- Fixes: #114
- Fixes: #116
- Fixes: #117
- Fixes: #120

References:
1. https://bugs.python.org/issue29930
2. https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-asyncawait-world/
3. aio-libs/aiohttp#1369
@lock
Copy link

lock bot commented Oct 29, 2019

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.

@lock lock bot added the outdated label Oct 29, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants