[issue44075] Add a PEP578 audit hook for Asyncio loop stalls
New submission from Tom Forbes : Detecting and monitoring loop stalls in a production asyncio application is more difficult than it could be. Firstly you must enable debug mode for the entire loop then you need to look for warnings outputted via the asyncio logger. This makes it hard to send loop stalls to monitoring systems via something like statsd. Ideally asyncio callbacks would always be timed and an auditevent always triggered if it passes a particular threshold. If debug mode is enabled then a warning is logged. -- components: asyncio messages: 393251 nosy: asvetlov, orf, yselivanov priority: normal severity: normal status: open title: Add a PEP578 audit hook for Asyncio loop stalls type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44075] Add a PEP578 audit hook for Asyncio loop stalls
Tom Forbes added the comment: I don't see why we shouldn't use PEP 578 for this - the events provide rich monitoring information about what a Python process is "doing" with an easy, central way to register callbacks to receive these events and shovel them off to a monitoring solution. Is there that much of a difference between monitoring the number of files, sockets, emails or even web browsers opened and the number of times an asyncio application has stalled? The alternative would be to make the loop stalling some kind of hookable event, which just seems like reinventing `sys.audit()`. -- ___ Python tracker <https://bugs.python.org/issue44075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44075] Add a PEP578 audit hook for Asyncio loop stalls
Change by Tom Forbes : -- keywords: +patch pull_requests: +24642 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25990 ___ Python tracker <https://bugs.python.org/issue44075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44075] Add a PEP578 audit hook for Asyncio loop stalls
Tom Forbes added the comment: Actually reacting to a stall would require something more and probably should be done at some point. But this is purely about monitoring - in our use case we'd send a metric via statsd that would be used to correlate stalls against other service level metrics. This seems pretty critical when running a large number of asyncio applications in production because you can only currently _infer_ that a stall is happening, and it's hard to trace the cause across service boundaries. An event hook that was sent the loop and handle would be ideal for this. -- ___ Python tracker <https://bugs.python.org/issue44075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41280] lru_cache on 0-arity functions should default to maxsize=None
New submission from Tom Forbes : `functools.lru_cache` has a maxsize=128 default for all functions. If a function has no arguments then this maxsize default is redundant and should be set to `maxsize=None`: ``` @functools.lru_cache() def function_with_no_args(): pass ``` Currently you need to add `maxsize=None` manually, and ensure that it is also updated if you alter the function to add arguments. -- components: Library (Lib) messages: 373542 nosy: Tom Forbes priority: normal severity: normal status: open title: lru_cache on 0-arity functions should default to maxsize=None type: performance versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31076] http.server should correctly handle HTTP 1.1 responses without a content-length
New submission from Tom Forbes: The builtin http.server module does not support HTTP keep-alive when sending a response without a content-length. This causes any clients to hang waiting on more response data, while the server hangs waiting for the client to send another request. This is documented (https://docs.python.org/3/library/http.server.html#http.server.BaseHTTPRequestHandler.protocol_version), but it is confusing. As far as I can tell the fix would be pretty simple: If no content-length header is set then close the connection regardless of the keep-alive header (Keep-alive is advisory and servers can close the connection at-will, regardless of what the client sends). If a response contains an inaccurate content-length header there is nothing we can do, but if none is present the server (and clients) should not just hang. -- components: Library (Lib) messages: 299471 nosy: Tom Forbes priority: normal severity: normal status: open title: http.server should correctly handle HTTP 1.1 responses without a content-length type: enhancement versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31076] http.server should correctly handle HTTP 1.1 responses without a content-length
Tom Forbes added the comment: Django recently switched to HTTP 1.1 on their development server, and it works fine as long as the middleware is included that generates the content length. Using a 'bare' Django project with no middleware the server will just hang. It sounds like the easiest fix is to disable keepalive support in the development server, which sounds like a reasonable fix (it doesn't have that much benefit locally I think?). It was certainly surprising to find this issue, I know it is documented but that could certainly be improved. It's currently just a plain line of text in quite a text-heavy page, perhaps it should be put in a warning box? -- ___ Python tracker <http://bugs.python.org/issue31076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
