История изменений для Celery 2.1¶

Исправления¶

• Опции выполнения в apply_async теперь имеют приоритет над опциями, возвращаемыми активными маршрутизаторами. Это была регрессия, внесенная недавно (выпуск #244).

• монитор curses: Длинные аргументы теперь усекаются, поэтому curses не падает при ошибках, выходящих за границы (проблема #235).

• multi: Ошибки канала, возникающие при обработке команд управления, больше не приводят к аварийному завершению работы, а регистрируются с ошибкой серьезности.

• Бэкенд базы данных SQLAlchemy: Исправлено состояние гонки, возникавшее при записи клиентом состояния ожидания. Как и бэкенд базы данных Django, он больше не сохраняет состояние ожидания (Выпуск #261 + Выпуск #262).

• В теле письма с ошибкой теперь используется repr(exception) вместо str(exception), так как последнее могло привести к ошибкам декодирования Unicode (проблема #245).

• Значение тайм-аута отправки сообщений об ошибках теперь настраивается с помощью параметра EMAIL_TIMEOUT.

• celeryev: Теперь работает под Windows (но монитор curses не будет работать без наличия curses).

• Вывод модульных тестов больше не выдает нестандартные символы.

• рабочий: Потребитель широковещания теперь закрывается при сбросе соединения.

• рабочий: Теперь правильно обрабатывает ошибки, возникающие при попытке подтвердить сообщение.

• TaskRequest.on_failure теперь кодирует трассировку с использованием текущей файловой системы

  кодировки (проблема #286).

• EagerResult теперь можно мариновать (проблема #288).

Документация¶

• Добавление Contribution getting started.

• Добавлено Оптимизация.

• Добавлен раздел Безопасность в FAQ.

Исправления¶

• worker: Теперь посылает событие task-retried для повторно выполненных заданий.

• worker: Теперь почетное игнорирование результата для WorkerLostError и ошибок таймаута.

• celerybeat: Исправлено UnboundLocalError в celerybeat логировании при использовании сигналов настройки логирования.

• рабочий: Все сообщения журнала теперь включают exc_info.

Исправления¶

• Теперь снова работает в Windows.

  Удалена зависимость от модулей <<<0 >>>/<<<1 >>>.

• моментальные снимки: Исправлено состояние гонки, приводящее к потере событий.

• рабочий: Отклонять задания с ETA, которое нельзя преобразовать в метку времени.

  Смотрите выпуск #209

• concurrency.processes.pool: Семафор был освобожден дважды для каждой задачи (и при ACK, и при готовности результата).

  Это было исправлено, и теперь он выпускается только один раз для каждого задания.

• docs/configuration: Исправлена опечатка CELERYD_TASK_SOFT_TIME_LIMIT -> CELERYD_TASK_SOFT_TIME_LIMIT.

  Смотрите выпуск №214

• управляющая команда dump_scheduled: использовался старый атрибут .info

• multi: Исправлена ошибка set changed size during iteration.

  возникающие при выполнении команды перезапуска.

• рабочий: Случайно попытался использовать дополнительные аргументы командной строки.

  Это приведет к ошибке типа:

  получил несколько значений для ключевого аргумента „concurrency“.

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

• celerybeat: Теперь снова уважает маршрутизаторы и варианты выполнения задач.

• celerybeat: Теперь вместо соединения повторно используется издатель.

• Бэкенд результатов кэширования: Использование float в качестве аргумента expires в cache.set устарело в библиотеках Memcached, поэтому теперь мы автоматически приводим к int.

• модульные тесты: Больше не выводит логи и предупреждения в выводе тестов.

Новости¶

• Теперь зависит от версии моркови 0.10.7.

• Добавлены настройки CELERY_REDIRECT_STDOUTS, и << 1 >>>.

  CELERY_REDIRECT_STDOUTS используется рабочим и beat. Весь вывод в stdout и stderr будет перенаправлен в текущий логгер, если он включен.

  CELERY_REDIRECT_STDOUTS_LEVEL определяет используемый уровень журнала и по умолчанию составляет WARNING.

• Добавлена настройка CELERYBEAT_SCHEDULER.

  Этот параметр используется для определения значения по умолчанию для опции -S - celerybeat.

  Пример:

  CELERYBEAT_SCHEDULER = 'djcelery.schedulers.DatabaseScheduler'
  

• Добавлена функция Task.expires: Используется для установки времени истечения срока действия по умолчанию для задач.

• Новые команды дистанционного управления: add_consumer и cancel_consumer.

  add_consumer(queue, exchange, exchange_type, routing_key,

  \*\*options)

  Приказывает рабочему объявлять и потреблять из указанного объявления.

  cancel_consumer(queue_name)¶

  Приказывает рабочему прекратить потребление из очереди (по имени очереди).

  Также добавлены команды celeryctl и inspect.

  Пример использования celeryctl для начала потребления из очереди «queue», в обмене «exchange», типа «direct», используя ключ привязки «key»:

  $ celeryctl inspect add_consumer queue exchange direct key
  $ celeryctl inspect cancel_consumer queue
  

  Более подробную информацию о программе Утилиты командной строки управления (inspect/control) см. в разделе celeryctl.

  Другой пример с использованием inspect:

  >>> from celery.task.control import inspect
  >>> inspect.add_consumer(queue='queue', exchange='exchange',
  ...                      exchange_type='direct',
  ...                      routing_key='key',
  ...                      durable=False,
  ...                      auto_delete=True)
  
  >>> inspect.cancel_consumer('queue')
  

• celerybeat: Теперь регистрируется обратная трассировка, если сообщение не может быть отправлено.

• celerybeat: Теперь по умолчанию таймаут сокета составляет 30 секунд.

• README/введение/домашняя страница: Добавлена ссылка на Flask-Celery.

Важные замечания¶

• Celery теперь следует семантике версионности, определенной semver.

  Это означает, что мы больше не можем использовать семантику четных/нечетных версий По нашей предыдущей схеме версионирования этот стабильный выпуск должен был быть версией 2.2.

• Теперь зависит от Carrot 0.10.7.

• Больше не зависит от SQLAlchemy, его нужно установить отдельно, если используется бэкенд результатов базы данных.

• django-celery теперь поставляется с монитором для интерфейса Django Admin. Его также можно использовать, если вы не являетесь пользователем Django. (Обновление: монитор Django-Admin был заменен на Flower, см. руководство по мониторингу).

• Если после обновления вы получите ошибку: AttributeError: „module“ object has no attribute „system“,

  Тогда это происходит потому, что модуль celery.platform был переименован в celery.platforms, чтобы не столкнуться со встроенным модулем platform.

  Вы должны удалить старый файл platform.py (и, возможно, platform.pyc) из предыдущей установки Celery.

  Для этого используйте python, чтобы найти местоположение этого модуля:

  $ python
  >>> import celery.platform
  >>> celery.platform
  <module 'celery.platform' from '/opt/devel/celery/celery/platform.pyc'>
  

  Здесь скомпилированный модуль находится в /opt/devel/celery/celery/, чтобы удалить нарушающие правила файлы do:

  $ rm -f /opt/devel/celery/celery/platform.py*
  

Новости¶

• Добавлена поддержка истечения срока действия результатов AMQP (требуется RabbitMQ 2.1.0)

  Новый параметр конфигурации CELERY_AMQP_TASK_RESULT_EXPIRES устанавливает время истечения срока действия в секундах (может быть int или float):

  CELERY_AMQP_TASK_RESULT_EXPIRES = 30 * 60  # 30 minutes.
  CELERY_AMQP_TASK_RESULT_EXPIRES = 0.80     # 800 ms.
  

• celeryev: Снимки событий

  Если функция включена, рабочий отправляет сообщения о том, что он делает. Эти сообщения называются «событиями». События используются мониторами реального времени, чтобы показать, что делает кластер, но они не очень полезны для мониторинга в течение длительного периода времени. Снимки позволяют делать «снимки» состояния кластеров через регулярные промежутки времени. Затем эти снимки можно сохранить в базе данных для получения статистики или даже для мониторинга за более длительные периоды времени.

  django-celery теперь поставляется с монитором Celery для интерфейса Django Admin. Для его использования вам необходимо запустить камеру моментальных снимков django-celery, которая сохраняет моментальные снимки в базу данных через настраиваемые интервалы времени.

  Чтобы использовать монитор администратора Django, вам нужно сделать следующее:

  1. Создайте новые таблицы базы данных:

     $ python manage.py syncdb
     

  2. Запустите камеру моментального снимка django-celery:

     $ python manage.py celerycam
     

  3. Откройте админку django для мониторинга вашего кластера.

  Интерфейс администратора показывает задания, рабочие узлы и даже позволяет выполнять некоторые действия, например, отзывать и ограничивать задания, а также выключать рабочие узлы.

  Также доступен скрипт Debian init.d для events, более подробную информацию смотрите в Демонизация.

  Новые аргументы командной строки для celeryev:

  • celery events --camera: Используемый класс камеры моментального снимка.

  • celery events --logfile: Файл журнала

  • celery events --loglevel: Уровень журнала

  • celery events --maxrate: Ограничение скорости затвора.

  • celery events --freq: Частота затвора

  Аргумент --camera - это имя класса, с помощью которого делаются снимки. Он должен поддерживать интерфейс, определенный аргументом celery.events.snapshot.Polaroid.

  Частота срабатывания затвора управляет тем, как часто просыпается поток камеры, а ограничение скорости - тем, как часто он будет делать снимки. Ограничение скорости может быть целым числом (снимки/с) или строкой ограничения скорости, которая имеет тот же синтаксис, что и строки ограничения скорости задачи (200/m, 10/s, 1/h и т.д.).

  Для случая камеры Django это ограничение скорости может использоваться для контроля частоты записи снимков в базу данных, а частота используется для контроля частоты пробуждения потока, чтобы проверить, есть ли что-то новое.

  По умолчанию ограничение скорости отключено, что означает, что снимок будет делаться каждые --frequency секунд.

• broadcast(): Добавлен аргумент обратного вызова, который можно использовать для обработки ответов сразу после их получения.

• celeryctl: Новая утилита командной строки для управления и проверки рабочих узлов, применения задач и проверки результатов выполнения задач.

  См.также

  Раздел Утилиты командной строки управления (inspect/control) в Руководство пользователя.

  Некоторые примеры:

  $ celeryctl apply tasks.add -a '[2, 2]' --countdown=10
  
  $ celeryctl inspect active
  $ celeryctl inspect registered_tasks
  $ celeryctl inspect scheduled
  $ celeryctl inspect --help
  $ celeryctl apply --help
  

• Добавлена возможность устанавливать дату и время истечения срока действия для задач.

  Пример:

  >>> # Task expires after one minute from now.
  >>> task.apply_async(args, kwargs, expires=60)
  >>> # Also supports datetime
  >>> task.apply_async(args, kwargs,
  ...                  expires=datetime.now() + timedelta(days=1)
  

  Когда работник получает задание, срок выполнения которого истек, оно будет помечено как отозванное (TaskRevokedError).

• Изменен способ конфигурирования протоколирования.

  Теперь мы настраиваем корневой регистратор вместо того, чтобы настраивать только наш пользовательский регистратор. Кроме того, мы больше не захватываем многопроцессорный логгер, а используем пользовательское имя логгера для разных приложений:

  Приложение	Имя регистратора
  celeryd	"celery"
  celerybeat	"celery.beat"
  celeryev	"celery.ev"

  Это означает, что аргументы loglevel и logfile будут влиять на все зарегистрированные логгеры (даже на те, которые получены из сторонних библиотек). Если только вы не настроите регистраторы вручную, как показано ниже.

  Пользователи могут настроить ведение журнала, подписавшись на сигнал :signal:`~celery.signals.setup_logging`:

  from logging.config import fileConfig
  from celery import signals
  
  @signals.setup_logging.connect
  def setup_logging(**kwargs):
      fileConfig('logging.conf')
  

  Если нет приемников для этого сигнала, подсистема протоколирования будет настроена с помощью аргументов --loglevel/ << 1 >>>, это будет использоваться для всех определенных протоколирующих устройств.

  Помните, что рабочий также перенаправляет stdout и stderr в регистратор Celery, если вы вручную настраиваете ведение журнала, вам также необходимо перенаправить стандартные выходы вручную:

   from logging.config import fileConfig
   from celery import log
  
  def setup_logging(**kwargs):
       import logging
       fileConfig('logging.conf')
       stdouts = logging.getLogger('mystdoutslogger')
       log.redirect_stdouts_to_logger(stdouts, loglevel=logging.WARNING)
  

• worker Добавлен параметр командной строки --include:

  Список модулей (задач), которые необходимо импортировать, разделенный запятыми.

  Пример:

  $ celeryd -I app1.tasks,app2.tasks
  

• worker: теперь выдает предупреждение, если выполняется от имени пользователя root (euid равен 0).

• celery.messaging.establish_connection(): Возможность переопределения значений по умолчанию, используемых с помощью аргумента ключевого слова «defaults».

• worker: Теперь использует multiprocessing.freeze_support(), так что он должен работать с py2exe, PyInstaller, cx_Freeze и т.д.

• рабочий: Теперь включает больше мета-данных для состояния STARTED: PID и имя хоста рабочего, который запустил задачу.

  Смотрите выпуск #181

• subtask: Объедините дополнительные аргументы ключевых слов для subtask() в аргументы ключевых слов задачи.

  Например:

  >>> s = subtask((1, 2), {'foo': 'bar'}, baz=1)
  >>> s.args
  (1, 2)
  >>> s.kwargs
  {'foo': 'bar', 'baz': 1}
  

  Смотрите выпуск #182.

• worker: Теперь выдает предупреждение, если на том же виртуальном узле уже есть рабочий узел с таким же именем.

• Бэкенд результатов AMQP: Отправка результатов теперь повторяется, если соединение прервано.

• Бэкенд результатов AMQP: result.get(): Ждать следующего состояния, если состояние не

  в READY_STATES.

• TaskSetResult теперь поддерживает подписку.

  >>> res = TaskSet(tasks).apply_async()
  >>> res[0].get()
  

• Добавлены Task.send_error_emails + Task.error_whitelist, так что они могут быть настроены для каждой задачи, а не только для глобальной настройки.

• Добавлено Task.store_errors_even_if_ignored, чтобы его можно было изменять для каждой задачи, а не только с помощью глобальной настройки.

• Планировщик Crontab больше не просыпается каждую секунду, а реализует remaining_estimate (Оптимизация).

• рабочий: Сохраните FAILURE результат, если

  WorkerLostError возникает исключение (рабочий процесс исчез).

• рабочий: Сохранять FAILURE результат, если происходит одно из исключений *TimeLimitExceeded.

• Рефакторинг периодической задачи, отвечающей за очистку результатов.

  • Задача по очистке бэкенда теперь добавляется в расписание только в том случае, если

    CELERY_TASK_RESULT_EXPIRES устанавливается.

  • Если расписание уже содержит периодическую задачу с именем «celery.backend_cleanup», оно не будет ее менять, поэтому поведение задачи очистки бэкенда можно легко изменить.

  • Теперь задание выполняется каждый день в 4:00 утра, а не каждый день с момента первого запуска (используя Crontab schedule вместо run_every).

  • Переименована celery.task.builtins.DeleteExpiredTaskMetaTask.

    -> celery.task.builtins.backend_cleanup

  • Сама задача была переименована из «celery.delete_expired_task_meta» в «celery.backend_cleanup».

  Смотрите выпуск #134.

• Реализована функция AsyncResult.forget для бэкендов SQLAlchemy/Memcached/Redis/Tokyo Tyrant (забывание и удаление результата задачи).

  Смотрите выпуск #184.

• TaskSetResult.join: Добавлен аргумент „propagate=True“.

  Если установлено значение False исключения, возникающие в подзадачах, не будут повторно подниматься.

• Добавлено Task.update_state(task_id, state, meta) в качестве сокращения для task.backend.store_result(task_id, meta, state).

  Интерфейс бэкенда является «приватным», а терминология устарела, поэтому лучше перенести его в Task, чтобы его можно было использовать.

• timer2: Установите self.running=False в stop(), чтобы он не пытался присоединиться снова при последующих вызовах stop().

• Цвета журнала теперь отключены по умолчанию в Windows.

• celery.platform переименован в celery.platforms, чтобы не сталкиваться со встроенным модулем platform.

• Исключения, возникающие в обратных вызовах Mediator+Pool, теперь перехватываются и регистрируются в журнале вместо того, чтобы завершать работу рабочего.

• Бэкенд результатов Redis: Теперь поддерживает истечение срока действия результатов с помощью команды Redis EXPIRE.

• модульные тесты: Не оставляйте потоки запущенными при завершении работы.

• рабочий: Результаты задач, отображаемые в журналах, теперь усекаются до 46 символов.

• Task.__name__ теперь является псевдонимом для self.__class__.__name__.

  Таким образом, задачи интроспекции больше похожи на обычные функции.

• Task.retry: Теперь поднимает TypeError, если аргумент kwargs пуст.

  Смотрите выпуск #164.

• timedelta_seconds: Используйте timedelta.total_seconds, если работаете на Python 2.7

• TokenBucket: Общий алгоритм Token Bucket

• celery.events.state: Запись состояния кластера теперь может быть приостановлена и возобновлена, включая поддержку буферизации.

  State.freeze(buffer=True)¶

  Приостанавливает запись потока.

  Если buffer имеет значение true, события, полученные во время заморозки, будут буферизированы и могут быть воспроизведены позже.

  State.thaw(replay=True)¶

  Возобновляет запись потока.

  Если replay равно true, то будет применен записанный буфер.

  State.freeze_while(fun)¶

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

• EventReceiver.capture Теперь поддерживается аргумент с ключевым словом timeout.

• worker: Поток посредника теперь отключен, если включено CELERY_RATE_LIMITS, и задания напрямую отправляются в пул, не проходя через очередь готовности (Оптимизация).

Исправления¶

• Пул: Процесс, завершившийся по таймауту TimeoutHandler, должен быть присоединен к супервизору, поэтому не удаляйте его из списка внутренних процессов.

  Смотрите выпуск #192.

• TaskPublisher.delay_task теперь поддерживает аргумент exchange, поэтому exchange можно переопределить при массовой отправке заданий с помощью одного издателя

  Смотрите выпуск #187.

• рабочий больше не помечает задания как отозванные, если включено CELERY_IGNORE_RESULT.

  См. выпуск #207.

• Бэкенд AMQP Result: Исправлена ошибка с result.get(), если включено CELERY_TRACK_STARTED.

  result.get() прекращал бы потребление после получения состояния STARTED.

• Исправлена ошибка, при которой новые процессы, созданные супервизором пула, застревали при чтении из очереди задач.

  См. http://bugs.python.org/issue10037

• Исправлена временная проблема при объявлении очереди ответов на команды дистанционного управления

  Эта проблема могла привести к потере ответов, но теперь она исправлена.

• Реализация LoggerAdapter с обратной совместимостью: Теперь работает для Python 2.4.

  Также добавлена поддержка нескольких новых методов: fatal, makeRecord, _log, log, isEnabledFor, addHandler, removeHandler.

Экспериментальный¶

• multi: Добавлена поддержка демонизации.

  multi теперь можно использовать для запуска, остановки и перезапуска рабочих узлов:

  $ celeryd-multi start jerry elaine george kramer
  

  При этом также создаются файлы PID и файлы журнала (celeryd@jerry.pid, …, celeryd@jerry.log. Чтобы указать местоположение этих файлов, используйте аргументы –pidfile и –logfile в формате %n:

  $ celeryd-multi start jerry elaine george kramer \
                  --logfile=/var/log/celeryd@%n.log \
                  --pidfile=/var/run/celeryd@%n.pid
  

  Остановка:

  $ celeryd-multi stop jerry elaine george kramer
  

  Перезапуск. Узлы будут перезапускаться один за другим по мере выключения старых узлов:

  $ celeryd-multi restart jerry elaine george kramer
  

  Убийство узлов (ПРЕДУПРЕЖДЕНИЕ: будут отброшены выполняемые в данный момент задачи):

  $ celeryd-multi kill jerry elaine george kramer
  

  За справкой обращайтесь к celeryd-multi help.

• multi: команда start переименована в show.

  Теперь celeryd-multi start будет действительно запускать и отсоединять рабочие узлы. Чтобы просто сгенерировать команды, нужно использовать celeryd-multi show.

• worker: Добавлен аргумент –pidfile.

  Рабочий будет записывать свой pid при запуске. Рабочий не будет запущен, если этот файл существует и содержащийся в нем pid еще жив.

• Добавлен общий скрипт init.d, использующий celeryd-multi.

  https://github.com/celery/celery/tree/master/extra/generic-init.d/celeryd

Документация¶

• Добавлен раздел руководства пользователя: Мониторинг

• Добавлен раздел руководства пользователя: Периодические задачи

  Перемещено из getting-started/periodic-tasks и обновлено.

• tutorials/external перемещены в новый раздел: «сообщество».

• Ссылки были добавлены во все разделы документации.

  Это облегчает установление связей между документами.