Сельдерей - повторная отправка неудачной цепочки задач после превышения максимального числа повторных попыток

Я использую сельдерей с джанго. Я должен предоставить пользователю возможность проверить невыполненную задачу, при необходимости внести изменения в данные неудачной задачи и отправить их снова. Я видел эту ветку - Celery Хранение неисправимых сбоев задач для последующей повторной отправки . Итак, я понимаю, что сельдерей не хранит исходные аргументы и кварги задачи, и мы должны позаботиться об этом. Я согласен с этим. Но если у меня есть основная задача «MainTask1», которая отправляет цепочку «SubTask1 | SubTask2 | SubTask3», и если SubTask2 терпит неудачу, то я вижу, что SubTask3 не будет выполняться до тех пор, пока SubTask2 не завершится успешно. Но если подзадача2 завершается неудачно после максимального количества повторных попыток, то подзадача3 никогда не отправляется.

Мои вопросы -

  1. Когда подзадача2 терпит неудачу, я могу сохранить аргументы и kwargs этого. Но как мне получить информацию об остальных задачах в цепочке?

  2. Что именно хранится в столбцах «результат» и «мета» таблицы celery_taskmeta?

  3. Когда заполняется таблица celery_tasksetmeta?

Спасибо,


person ksrini    schedule 15.11.2012    source источник


Ответы (1)


  1. Для этого вы можете использовать результаты (например, AsyncResult(id).ready, см. http://docs.celeryproject.org/en/latest/reference/celery.result.html), но это не может быть надежно выполнено с помощью серверной части amqp, поскольку только один процесс может получить результат.

  2. Имена, используемые в серверном APi, несовместимы и устарели. Это связано с тем, что терминология со временем изменилась, а серверные части были в значительной степени обратно совместимы, начиная с celery 0.1. Сначала задачи сохраняли данные только тогда, когда они были успешными или неудачными. При этом использовались поля status и result. В конце концов я понял, что это легко расширить до поддержки произвольных состояний, которые обновляются по мере выполнения задачи, и это было просто реализовано поверх того, что уже существовало.

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

    Мета-поле было добавлено позже, потому что мне надоело все время добавлять новые поля (и заставлять пользователей переносить схему), оно используется для новых полей, которые не нужно индексировать, и в настоящее время оно содержит только атрибут children, который является список идентификаторов подзадач, запущенных задачей

    Надеюсь, когда-нибудь это удастся исправить. Большинство других «проблем роста» уже много лет назад было устранено, но результат остался.

  3. GroupResult.save (ранее TaskSetResult) используется для хранения результата группы для последующего извлечения, поэтому вы можете получить список идентификаторов задач в группе, просто сохраняя идентификатор группы. Эта функция используется только серверной частью результатов Redis для реализации аккордов на этом этапе, это изменится в будущем, потому что это не очень эффективно для групп с большим количеством задач. Опция сохранения была реализована по запросу пользователя, но я считаю, что это был плохой выбор с моей стороны, и было бы лучше, если бы пользователь это сделал (например, сохранение аргументов задачи / kwargs, о которых вы упомянули).

person asksol    schedule 06.12.2012
comment
Спасибо за обновления. Я использую amqp для бэкэнда. На данный момент я решил не использовать примитив цепочки. Вместо этого я заставляю каждую задачу отправлять следующую задачу, тем самым моделируя цепочку. Я решил использовать столбцы result и meta, извлекая данные из таблицы результатов. - person ksrini; 07.12.2012
comment
@ksrini, Вам ответил создатель сельдерея :) - person Pol; 08.12.2012
comment
@Pol, да я это понял. :) - person ksrini; 10.12.2012