Adds gevent based worker as alternative. #943
Conversation
|
It's hard for us to maintain multiple transports with the same stability guarantees. While I apprechiate the contribution, is there a particular instance where the thread-based transport has posed a problem for you? |
|
I use my own custom built WSGI framework and it does not play well with threading. Either I would get random lock ups or sentry_sdk did not send any events. If I messed around a bit more I might have been able to patch work something together but writing a custom transport/worker seemed much easier and more efficient. Generally the interaction between the two is a bit questionable, since monkeypatching threading means threads will be greenlets, which means the synchronization primitives need to be patched properly as well, but you're rolling your own Queue and pseudo implement JoinableQueue within the worker itself, so gevent will not be able to mimic the worker job dispatch in quite the same way. Generally I don't care too much what you do with this. I needed it for my project and it took me a couple of hours to implement at most, so I thought I'd be nice and invest the half hour in creating a pull request, so you could use it if you wanted it. Also technically it is not a different transport, it's just a gevent friendly implementation of the background worker, so the maintainability cost should be lower compared to raven. I could try to decrease the surface area of this patch by formally implementing your custom JoinableQueue instead of rolling it into the worker. That would allow for a slightly more generic implementation where the two workers are essentially the same apart from thread/greenlet start and kill and which classes they use for their synchronization primitives. So you'd just have to overwrite its primitives and the start/kill methods. |
|
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
|
documented in #1484 (comment) and closing |
While having sentry_sdk running on its own thread by default is a good default, it was handy to have asynchronous options in raven as alternatives.
Particularly gevent can be a bit dodgy when combined with threading and uwsgi. You can technically make it work, but there are valid reasons, why you may not wish to. Explicitly using greenlets instead of threads instead of relying on the monkey patching to work in conjunction with the modified stdlb Queue is a bit more robust.
That is why I added a gevent based worker that uses the gevent synchronization primitives.
Like custom transports it can be passed via options["worker"]. Right now only HttpWorker will make use of it, but there are no other workers yet, apart from the function based ones.