-
Notifications
You must be signed in to change notification settings - Fork 227
Investigate options to support async (Twisted) #16
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
Comments
For Tornado, we could potentially piggyback on I haven't found something similar for Twisted. There is some discussion around context tracking here, but the general advice there seems to be against trying to use |
There's some more development in this space:
All of these are built around asyncio though, so I'm not sure of how much benefit either one would be in conjunction with Twisted and Tornado (both of which use their own event loop implementation) |
See #252 for a very WIPy implementation of asyncio support |
The asgi apps are starting to gain traction, and are a compelling alternative to Go, Node, etc for better concurrency in heavy IO blocking apps. APM support is a sticking point for me in building apps this way (Starlette in particular) and I’d love to see support in this area, or even recommendations on how to get partial support of some kind (ie. request timing) working. Thanks! |
Another asynchronous framework quite used by python projects is gevent. Needless to say currently that's not supported by the apm-agent-python. The first significant effect is that transactions are not being supported. While I appreciate the initial design decision which were mentioned by the OP in the first post would you guys consider supporting something like gevent ? I'm thinking you might be able to use |
We have support for tornado, starlette/fastapi and various async libraries as well. If there's continued interest in gevent, twisted, or others, we request that separate issues be made. |
Uh oh!
There was an error while loading. Please reload this page.
We currently don't support any asynchronous Python frameworks like Twisted, Tornado & Co. Supporting these frameworks is inherently difficult due to the fact that we made a lot of design decisions on the assumption that a thread only handles a single request at a time. This is not true for async frameworks.
There are some ways we could achieve at least some support for Twisted by storing data of the current transaction on the request handler instead of a thread local. Similar workarounds may or may not exist for other async frameworks.
In the future, we may be able to use execution contexts as proposed by PEP 550, but this will take some time until it is available.
The text was updated successfully, but these errors were encountered: