Django-utils @async декоратор и gunicorn не работают

Question

Я использую djutils @async декоратор для асинхронного вызова функции.Это хорошо работает, когда я запускаю свой сервер со стандартной командой ./manage.py runserver.Но когда я запускаю свое приложение django под gunicorn и вызываю функцию с помощью декоратора @async, ничего не происходит вообще ...

Я изучил код асинхронного декоратора djutils, и он добавляет и возражает против питона-стандартная очередь, а также порождение одного или нескольких потоков для использования очереди.

У кого-нибудь есть идея или подсказка, где мне следует искать дальше, чтобы мои функции @async работали в gunicorn?Gunicornn меняет стандартную реализацию реализации потока Python?

Answer 1

Потоки Python подвержены вмешательству из-за глобальной блокировки интерпретатора, и Gunicorn, скорее всего, обезьяны, исправляя поведение потоков по умолчанию. Таким образом, вы можете попробовать изменить его тип работника. Если ваш Gunicorn настроен на использование асинхронных рабочих с Gevent, то он может обезопасить ветку Thread, потому что Gevent может это сделать, заменив класс потока на «зеленый» поток, который сотрудничает.

Лично я ненавижу ответы "делай это по-другому", извините за то, что дал один. Не создавайте потоки или процессы ветвления внутри процесса вашего веб-сервера. Просто перенесите эту работу в фоновую очередь.

Создать собственную фоновую очередь легко, если у вас есть простые потребности. В вашей базе данных есть таблица, в которой регистрируются ожидающие и завершенные задания в сочетании со скриптом cron, который выполняется каждые 5 минут или около того и работает оттуда.

А если вам нужно что-то стабильное и способное масштабироваться, Сельдерей довольно хорошо.

Answer 2

Код (в djutils / decorators.py) для запуска потоков, обрабатывающих элементы в очереди, вызывается при первом запуске gunicorn, то есть он вызывается для основного процесса gunicorn. Тем не менее, gunicorn затем раскроет несколько рабочих процессов. После этого код для запуска потоков НЕ вызывается повторно. Таким образом, эти фоновые потоки присутствуют только в мастер-процессе Gunicorn, а не в любом из рабочих процессов Gunicorn.