(50$) Python celery, исправить баг

Жаль питон не знаю, а так бы взялся.

P.S. Судя по активности треда, зажрались.

Жаль питон не знаю, а так бы взялся.

жаль шутить не умею, а так бы пошутил на эту тему

:D, ты не понял скрытый смысл моего сообщения

Кажется, пофиксил ошибку. Попробуй склонировать мой форк, установить его в виртуальное окружение через python setup.py install и проверить, работает ли у тебя.

А что на четвертый не перейти?

Нужно для celery версии 3 :) (как указано в первом посте, хотя конечно понять это двояко можно), если вся суть в этом commit'е то я для третьей версии сделал изменения по тому же принципу вот здесь, затем почистил кэш в той папке, и проверил - не работает.

Кто именно зажрался?

Хорошая шутка! Схоронил.

Поясните пожалуйста мне невежественному, какой был скрытый смысл? И почему бы его прямо было не написать?

Третья celery поддерживает windows (4-ка уже нет, отказались), клиент которому пишу проект требует кроссплатформенность.

клиент которому пишу проект

Нанять программиста для того чтобы нанять программиста.

дикаприо.jpg, на самом деле не такая уже и редкая ситуация, а ещё бывает что клиент который у меня заказывает разработку сам является посредником

Не было ответов я провоцировал активность топика.

Ваш патч всё таки кое что полезное уже сейчас делает.

Раньше сообщения в главную очередь (main_check) улетали с такими свойствами:

reply_to:	96733d76-6645-37ea-a2ff-ae592d2f418f
correlation_id:	bac1fc81-5294-40be-a9ae-19223ca00784
priority:	0
delivery_mode:	2
headers:	
content_encoding:	utf-8
content_type:	application/json

Теперь с такими:

reply_to:	export_task
correlation_id:	826884a3-d585-4ae9-ab1f-d75b28905649
priority:	0
delivery_mode:	2
headers:	
content_encoding:	utf-8
content_type:	application/json

Как можно заметить reply_to в свойствах сообщения уже прописан как надо. Но celery всё равно это дело игнорирует, и как только я делаю вызов:

from my_worker import *
result = test_func.delay()

• 1. В главную очередь (main_check) улетает сообщение с правильными свойствами (reply_to указано как положено)
• 2. Но одновременно с этим создаётся ещё одна очередь с именем d5587446-0149-3133-a3ed-d9a297d52a96
• 3. Затем celery подхватывает таск из очереди main_check и результат пишет в эту левую очередь с именем d5587446-0149-3133-a3ed-d9a297d52a96

То есть Ваш патч частично помог, но celery по прежнему игнорирует reply_to свойства сообщений.

И точно также как и ранее это имя очереди совпадает со значением которое можно взять из кода вот так:

result.backend.binding.routing_key
# выдаст:
# d5587446-0149-3133-a3ed-d9a297d52a96

То есть можно сделать вывод, что где-то в коде который отвечает за обработку результатов кладётся болт за свойство сообщения reply_to.

Ваш патч всё таки кое что полезное уже сейчас делает

Остальное делает kombu и делает это правильно. Единственная проблема, которую я обнаружил — он не создаёт очередь для ответов сам.

Вот что происходит, если эту очередь создать вручную:

>>> from my_worker import *
>>> result = test_func.delay()
>>> result.backend.binding.routing_key
'0d214391-9fd6-328c-99b0-efbb3b600db7'

Но при этом вот, что происходит в rabbitmq:

$ watch rabbitmqctl list_queues name messages messages_ready messages_unacknowledged

Listing queues ...
celery@desktop.celery.pidbox    0       0       0
celeryev.3aa0dadd-7ebf-4b84-9d5c-5f46d34c5bf6   0       0       0
main_check      0       0       0
export_task  1       1       0
2e420616-a250-3f84-bb1d-b548ed89c57d    0       0       0

То есть несмотря на routing_key бэкенда, сообщения уходят в нужную очередь, и если создавать ещё таски, количество сообщений в очереди будет увеличиваться.

С Вами как-то есть возможность связаться по альтернативным каналам связи? jabber/mail например

Оставь свой jabber id, примерно через час освобожусь — напишу туда.

Вопрос решён, спасибо коллеге @grazor