-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Client timeout refactoring #2768
Comments
I agree the current situation is confusing, especially for beginners.
Maybe keyword arguments would be more canonical than chaining?
…On 26 Feb 2018 19:08, "Andrew Svetlov" ***@***.***> wrote:
There are many different timeout strategies for waiting a response from
client:
- uber timeout for total elapsed seconds
- timeout for waiting for available connection from a pool
- connection timeout for waiting a response from a new connection to
server
- timeout for getting HTTP headers from response
- timeout for every HTTP body chunk read
- maybe you can add your case
As the solution I propose collapsing all timeouts into the single
*timeout* class.
E.g. Timeout.after(30) is an uber timeout, Timeout.await_pool(5) is a
timeout for waiting for connection pool. Timeout.after(30).await_pool(5)
composes both.
Do you like the idea? Objections?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2768>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD2jGaeXk6Kx62Bsb4JuE8EXW46YAR1oks5tYwBjgaJpZM4STwZi>
.
|
Are you talking about keyword arguments in |
When a number is given, It should be converted to uber timeout. Keyword-arguments for constructor may be better. Though chaining is cool, for the real usage, many applications may use configuration dict to store the settings, so keyword arguments would be more convient. Timeout object should work like dict, so a request timeout object can be merged into the default settings. |
No. Disabling a waiting for available connection is preferable in many cases, aiobotocore wants it. |
Maybe use False or a specified constant for "explicit disable"? Allow inheriting from default is always useful I think. |
I'm totally missed what default are you talking about and what inheriting means in this context? |
I think there should be a default timeout settings on the session? And for each request, a different timeout can be specified. |
Yes. Like now a client session has default timeouts which could be overridden by request. |
another possible timeout:
I'm not sure if the "send" of the headers blocks, if so I guess that could be a timeout, but more of a "write" timeout. aiobotocore want's "normal" timeouts, that is timeouts should encapsulate actual network lag. So:
|
Definitely, this is something that has appeared many times and needs to be tackled sooner than later. My 2cents on that:
Will be appreciated a snippet showing the use case. Regarding the
We could give a new option that would allow the developer to get notified via an |
@pfreixes ya I think there are two categories, those that should be specifiable, and those that are traceable. For now we're only interested in tracing |
@asvetlov When we choose a timeout object for the session which contains uber timeout and connect timeout, and then start a request with a timeout object that cancels the uber timeout, usually we still want to keep the connect timeout. So timeout object should be able to merge. I suggest that the timeout object has following interfaces:
NOTICE: |
I dislike timeout merging and dict exposing, it brings unnecessary complexity. |
@pfreixes I don't see backward compatibility problems. For transition period a timeout is constructed from old-styled parameters if not provided explicitly. |
@thehesiod tracing is very reach word with many contexts. |
@asvetlov sorry I didn't quite understand your message, but to clarify, in regards to the subject of the time to acquire a connector from the pool, I'm only interested in that time for tracing (ddtrace, aws-xray, etc), I don't need to specify a timeout for that, nor do I want it included in other fine-grained timeouts. Hope that helps |
In my mind tracing is not related to timeouts problem discussed here. |
you already have signals for that on_connnection_queued_strart and
on_connection_queued_end
El 28/02/2018 07:54, "Andrew Svetlov" <[email protected]> escribió:
… In my mind tracing is not related to timeouts problem discussed here.
You should use client tracing API http://aiohttp.readthedocs.io/
en/stable/tracing_reference.html to measure different request lifecycle
times.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2768 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABK1iWvwGAnJNXNLPEnCywd6dvv4XLqaks5tZPhBgaJpZM4STwZi>
.
|
I'd really love to see more fine granular timeouts implemented, especially for not enforcing a timeout while waiting for a pooled connection, but only for actually establishing the TCP connection. This issue also seems to supersede a few other open issues, including #2648 and #2538. I do see a strong relation to the aiohttp tracing functionality as both tracing and timeouts hook into certain points of the request lifecycle. I think it might help to use the new block diagrams in the trace docs to discuss and later document which (groups of) states / transitions are counted towards which timeouts (see attached example for the timeout for establishing a new connection). |
To be clear: I have no estimation when I can find a time for the issue personally. |
@N-Coder ya that's why I brought it up. If I get any chance I'll try to come up with something. |
btw @N-Coder want to update your diagram for "read" timeouts as well? I'm not sure if that accounts for the header read, or just the body read(s). There's also redirects if you want to capture that as well from "request" to response" |
That was just one example on how one possible timeout could be visualised. ;) Just for reference here's how requests handles basic and advanced timeouts.
So to summarize all options on timeouts I found up to now in this thread (excluding anything on how the timeout might actually be specified in code):
Here are my comments:
I tried putting all the timeouts and states into a single diagram. Unfortunately, |
@N-Coder wow, thank you so much for that information! u rock! for 6 I'm guessing it's useful if you just want to specify an encompassing timeout and don't want to break up the timeout between the sub-parts, so basically either you set 6, or the sub-parts, but not both? btw for redirect, that could be to a different server so I'm assuming there are two branches? |
@N-Coder you are god for
This is exactly my main trouble: how to respect all possible timeouts without falling into combinatoric mess? |
Thanks! 😅
You're right, it might be worth to just keep it for convenience's sake. There might be some weird cases (although I can't come up with one right now), where somebody wants to set any 2 (or all 3) of timeouts 6, 2 and 3. Additionally, I can't come up with anything that speaks against keeping 6.
I'd say keep it simple and don't try to guess what the developer actually wants when setting any weird timeouts. Better make it really easy to understand which timeout affects what and don't involve any magic at all. I'd recommend only setting the two timeouts requests is also using (possibly to the same values) and leave the more advanced values to the more arcane use-cases, but without any complicated combinatoric interference. |
I just found #2310, #2537 and potentially also #2007 which are related to timeouts, but for the case of websockets. I'm not sure how far we should take websockets into account here, as at least the establishment of a connection takes at least one normal HTTP request and some of the timeouts for the websocket itself (e.g. a receive/read timeout for the TCP connection) might be similar. As I need working timeouts for another project soon and already got kind of an idea how they could be implemented properly, I'll try implementing and example we can discuss. |
Let's put websocket timeouts out of the issue scope for simplicity. |
I condensed my thoughts to code in PR #2842. Please don't see this as a complete PR ready for merging, it's just a draft intended as material for discussion. I had to make a PR to allow inline comments within the code to allow for easier reviewing. As soon as everything is settled, I'll make a proper, cleaned-up PR that makes the CI tools happy. I'm looking forward to your comments, idea, opinions, objections,... |
Done by #2972 |
This PR updates [aiohttp](https://pypi.org/project/aiohttp) from **3.2.1** to **3.3.1**. <details> <summary>Changelog</summary> ### 3.3.0 ``` ================== Features -------- - Raise ``ConnectionResetError`` instead of ``CancelledError`` on trying to write to a closed stream. (`2499 <https://github.com/aio-libs/aiohttp/pull/2499>`_) - Implement ``ClientTimeout`` class and support socket read timeout. (`2768 <https://github.com/aio-libs/aiohttp/pull/2768>`_) - Enable logging when ``aiohttp.web`` is used as a program (`2956 <https://github.com/aio-libs/aiohttp/pull/2956>`_) - Add canonical property to resources (`2968 <https://github.com/aio-libs/aiohttp/pull/2968>`_) - Forbid reading response BODY after release (`2983 <https://github.com/aio-libs/aiohttp/pull/2983>`_) - Implement base protocol class to avoid a dependency from internal ``asyncio.streams.FlowControlMixin`` (`2986 <https://github.com/aio-libs/aiohttp/pull/2986>`_) - Cythonize ``helpers.reify``, 5% boost on macro benchmark (`2995 <https://github.com/aio-libs/aiohttp/pull/2995>`_) - Optimize HTTP parser (`3015 <https://github.com/aio-libs/aiohttp/pull/3015>`_) - Implement ``runner.addresses`` property. (`3036 <https://github.com/aio-libs/aiohttp/pull/3036>`_) - Use ``bytearray`` instead of a list of ``bytes`` in websocket reader. It improves websocket message reading a little. (`3039 <https://github.com/aio-libs/aiohttp/pull/3039>`_) - Remove heartbeat on closing connection on keepalive timeout. The used hack violates HTTP protocol. (`3041 <https://github.com/aio-libs/aiohttp/pull/3041>`_) - Limit websocket message size on reading to 4 MB by default. (`3045 <https://github.com/aio-libs/aiohttp/pull/3045>`_) Bugfixes -------- - Don't reuse a connection with the same URL but different proxy/TLS settings (`2981 <https://github.com/aio-libs/aiohttp/pull/2981>`_) - When parsing the Forwarded header, the optional port number is now preserved. (`3009 <https://github.com/aio-libs/aiohttp/pull/3009>`_) Improved Documentation ---------------------- - Make Change Log more visible in docs (`3029 <https://github.com/aio-libs/aiohttp/pull/3029>`_) - Make style and grammar improvements on the FAQ page. (`3030 <https://github.com/aio-libs/aiohttp/pull/3030>`_) - Document that signal handlers should be async functions since aiohttp 3.0 (`3032 <https://github.com/aio-libs/aiohttp/pull/3032>`_) Deprecations and Removals ------------------------- - Deprecate custom application's router. (`3021 <https://github.com/aio-libs/aiohttp/pull/3021>`_) Misc ---- - 3008, 3011 ``` </details> <details> <summary>Links</summary> - PyPI: https://pypi.org/project/aiohttp - Changelog: https://pyup.io/changelogs/aiohttp/ - Repo: https://github.com/aio-libs/aiohttp </details>
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. |
There are many different timeout strategies for waiting a response from client:
As the solution I propose collapsing all timeouts into the single timeout class.
E.g.
Timeout.after(30)
is an uber timeout,Timeout.await_pool(5)
is a timeout for waiting for connection pool.Timeout.after(30).await_pool(5)
composes both.Do you like the idea? Objections?
The text was updated successfully, but these errors were encountered: