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

Исправления в системе безопасности¶

• [Безопасность: CELERYSA-0001] Демоны устанавливали эффективные, а не реальные идентификаторы, когда использовались аргументы --uid/ --gid для celery multi, celeryd_detach, celery beat и celery events.

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

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

• Теперь зависит от Kombu 1.1.2.

• В списках зависимостей теперь явно указывается, что нам не нужен python-dateutil 2.x, так как эта версия поддерживает только Python 3.

  Если вы случайно установили dateutil 2.0, вам следует перейти на версию 1.5.0:

  $ pip install -U python-dateutil==1.5.0
  

  или по easy_install:

  $ easy_install -U python-dateutil==1.5.0
  

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

• Новый WatchedFileHandler нарушил поддержку Python 2.5 (проблема #367).

• Задача: Не используйте app.main, если имя задачи задано явно.

• Отправка писем не работала на Python 2.5 из-за ошибки в коде определения версии (проблема №378).

• Бить: Добавляет метод ScheduleEntry._default_now

  Этот метод можно переопределить, чтобы изменить значение по умолчанию last_run_at.

• Ошибка, возникающая при очистке процесса, может маскировать ошибки задачи.

  Мы больше не распространяем ошибки, возникающие при очистке процесса, а записываем их в журнал. Таким образом, они не будут мешать публикации результата задачи (проблема № 365).

• Определение задач не работало должным образом при использовании утилиты Django shell_plus (проблема №366).

• AsyncResult.get не принял interval и << 2 >>>.

  аргументы.

• рабочий: Исправлена ошибка, при которой рабочий не отключался, если на экране появлялся

  socket.error был поднят.

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

• Теперь зависит от Kombu 1.0.7

Новости¶

• Наша документация теперь размещается на сайте Read The Docs (http://docs.celeryproject.org), и все ссылки были изменены, чтобы указывать на новый URL.

• Логирование: Теперь поддерживается ротация журнала с помощью внешних инструментов, таких как logrotate.d (выпуск #321)

  Это достигается с помощью команды WatchedFileHandler, которая повторно открывает файл, если он переименован или удален.

• otherqueues учебник теперь документирует, как настроить результат Redis/Database

  бэкенды.

• gevent: Теперь поддерживает задачи ETA.

  Но для работы gevent по-прежнему требуется CELERY_DISABLE_RATE_LIMITS=True.

• Руководство пользователя TaskSet: теперь содержит рецепты обратного вызова TaskSet.

• Эвентлет: Новые сигналы:

  • eventlet_pool_started

  • eventlet_pool_preshutdown

  • eventlet_pool_postshutdown

  • eventlet_pool_apply

  Дополнительную информацию см. в разделе celery.signals.

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

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

• TaskSet.apply/Taskset.apply_async теперь принимают необязательный аргумент taskset_id.

• Идентификатор taskset_id (если таковой имеется) теперь доступен в контексте запроса Task.

• Бэкенд результатов SQLAlchemy: столбцы taskset_id и taskset_id теперь имеют уникальное ограничение (таблицы должны быть созданы заново, чтобы это повлияло).

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

• Удален неиспользуемый атрибут AsyncResult.uuid.

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

• multiprocessing.Pool: Исправляет состояние гонки при маркировке задания с помощью WorkerLostError (выпуск #268).

  Возможно, процесс опубликовал результат до того, как был завершен, но у нас нет надежного способа определить, что это именно так.

  Поэтому мы должны подождать 10 секунд, прежде чем пометить результат с помощью WorkerLostError. Это дает обработчику результата шанс получить результат.

• multiprocessing.Pool: Выключение может зависнуть, если отключены ограничения скорости.

  Существовало состояние гонки, когда MainThread ждал освобождения семафора пула. Теперь ResultHandler завершается через 5 секунд, если есть нераспакованные задания, но нет рабочих процессов, которые могли бы их запустить (таймаут нужен, потому что все еще может быть ack+результат, который мы не получили из очереди результатов. Маловероятно, что мы получим их через 5 секунд при отсутствии рабочих процессов).

• celerybeat: Теперь создается pidfile, даже если опция --detach не установлена.

• eventlet/gevent: Потребитель широковещательных команд теперь работает в отдельном зеленом потоке.

  Это гарантирует, что широковещательные команды будут иметь приоритет, даже если есть много активных задач.

• Внутренний модуль celery.worker.controllers переименован в celery.worker.mediator.

• worker: Threads теперь завершает программу вызовом os._exit, поскольку это единственный способ обеспечить выход в случае синтаксических ошибок или других неустранимых ошибок.

• Исправлена опечатка в maybe_timedelta (выпуск #352).

• рабочий: Широковещательные команды теперь регистрируются с уровнем журнала debug вместо warning.

• AMQP Result Backend: Теперь сбрасывает кэшированный канал при потере соединения.

• Опрос результатов с помощью бэкенда результатов AMQP работал некорректно.

• Ограничения скорости: Больше не спит, если нет заданий, а ожидает условия получения задания (Улучшение производительности).

• ConfigurationView: iter(dict) должен возвращать ключи, а не элементы (проблема #362).

• celerybeat: PersistentScheduler теперь автоматически удаляет поврежденный файл расписания (проблема #346).

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

• Программы больше не пытаются загрузить файл конфигурации при отображении --version (проблема #347).

• Autoscaler: Сообщение журнала «все процессы заняты» теперь имеет категорию отладки, а не ошибки.

• рабочий: Если тело сообщения не может быть декодировано, то теперь оно передается через safe_str при регистрации.

  Это необходимо для того, чтобы не возникало дополнительных ошибок декодирования при попытке регистрации сбоя.

• app.config_from_object/app.config_from_envvar теперь работает для всех загрузчиков.

• Теперь выдает удобное для пользователя сообщение об ошибке, если имя бэкенда результата неизвестно (проблема №349).

• celery.contrib.batches: Теперь устанавливает loglevel и logfile в запросе задания, так что task.get_logger работает с пакетными заданиями (проблема #357).

• рабочий: При использовании транспорта amqp и превышении значения prefetch count более 65535 (проблема #359) возникало исключение.

  Счетчик предварительной выборки увеличивается для каждого полученного задания с определенным ETA/датой окончания. Счетчик предварительной выборки является коротким, поэтому может поддерживать только максимальное значение 65535. Если значение превышает максимальное значение, мы отключаем счетчик предварительной выборки, и он снова включается, как только значение снова становится меньше предела.

• cursesmon: Исправлена несвязанная локальная ошибка (выпуск #303).

• eventlet/gevent теперь импортируются по требованию, поэтому autodoc может импортировать модули без установленных eventlet/gevent.

• worker: Обратный вызов Ack теперь правильно обрабатывает AttributeError.

• Task.after_return теперь всегда вызывается после записи результата.

• Cassandra Result Backend: Теперь должен работать с последней версией pycassa.

• multiprocessing.Pool: Больше не беспокоит, если семафор putlock освобождается слишком много раз (это может произойти, если один или несколько рабочих процессов убиты).

• Бэкенд результатов SQLAlchemy: Теперь снова возвращает случайно удаленные date_done (проблема №325).

• Контекст Task.request теперь всегда инициализируется, чтобы вызов функции задачи напрямую работал, даже если она активно использует контекст запроса.

• Исключение, возникающее при итерации по результату из TaskSet.apply исправлено.

• eventlet: Теперь правильно планирует задачи с ETA в прошлом.

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

• worker: 2.2.3 нарушена регистрация ошибок, в результате чего трассировки не регистрировались.

• Бэкенд результатов AMQP: Опрос состояний задачи не работал должным образом, если в очереди было более одного сообщения о результате.

• TaskSet.apply_async() и TaskSet.apply() теперь поддерживают необязательный аргумент ключевого слова taskset_id (выпуск #331).

• Идентификатор текущего набора задач (если таковой имеется) теперь доступен в контексте задачи как request.taskset (выпуск #329).

• Бэкенд результатов SQLAlchemy: date_done больше не была частью результатов, так как была случайно удалена. Теперь она снова доступна (выпуск #325).

• Бэкенд результатов SQLAlchemy: Добавлено уникальное ограничение на Task.id и TaskSet.taskset_id. Таблицы должны быть созданы заново, чтобы это вступило в силу.

• Исправлено исключение, возникающее при итерации по результату TaskSet.apply().

• Руководство пользователя по задачам: Добавлен раздел о выборе бэкенда результатов.

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

• Теперь зависит от Kombu 1.0.3

• Task.retry теперь поддерживает аргумент max_retries, используемый для изменения значения по умолчанию.

• multiprocessing.cpu_count может поднять NotImplementedError на платформах, где это не поддерживается (проблема #320).

• Раскраска сообщений журнала нарушена, если объект журнала не является строкой.

• Исправлено несколько опечаток в документации по init-скрипту.

• Регрессия привела к тому, что Task.exchange и Task.routing_key больше не имели никакого эффекта. Теперь это исправлено.

• Руководство пользователя по маршрутизации: Исправлена опечатка, маршрутизаторы в CELERY_ROUTES должны быть экземплярами, а не классами.

• celeryev не создал pidfile, хотя аргумент --pidfile был задан.

• Формат регистратора задач больше не использовался (проблема №317).

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

• Безопасная версия repr() теперь используется в стратегически важных местах, чтобы объекты с нарушенной __repr__ не приводили к краху рабочего или другим трудноразличимым ошибкам (проблема #298).

• Команда удаленного управления active_queues: не учитывала очереди, добавленные во время выполнения.

  Кроме того, словарь, на который отвечает эта команда, теперь имеет другую структуру: ключ обмена теперь является словарем, содержащим декларацию обмена в полном объеме.

• Опция celery worker -Q удаляла неиспользуемые объявления очередей, поэтому маршрутизация заданий могла быть неудачной.

  Очереди больше не удаляются, а используется app.amqp.queues.consume_from() в качестве списка очередей для потребления.

  Это гарантирует, что все очереди доступны для маршрутизации.

• celeryctl: Теперь поддерживается команда inspect active_queues.

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

• celerybeat не смог правильно прочитать расписание, поэтому записи в CELERYBEAT_SCHEDULE не были запланированы.

• Сообщение журнала ошибок задачи теперь снова включает exc_info.

• Аргумент eta теперь можно использовать с task.retry.

  Ранее он перезаписывался аргументом обратного отсчета.

• celery multi/celeryd_detach: Теперь в журнал записываются ошибки, возникающие при выполнении команды celery worker.

• учебник по демонизации: Исправлена опечатка --time-limit 300 -> --time-limit=300

• Цвета в логировании нарушили нестроковые объекты в сообщениях журнала.

• setup_task_logger больше не делает предположений о kwargs магических задач.

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

• Пул эвентлетов утекал в память (проблема #308).

• Устаревшая функция celery.execute.delay_task была случайно удалена, теперь она снова доступна.

• BasePool.on_terminate заглушка не существовала

• celeryd_detach: Добавляет читабельные сообщения об ошибках, если имя пользователя/группы не существует.

• Более разумная обработка ошибок декодирования unicode при регистрации ошибок.

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

• Морковь была заменена на Kombu.

  Kombu - это библиотека обмена сообщениями нового поколения для Python, исправляющая несколько недостатков, присутствующих в Carrot, которые было трудно устранить без нарушения обратной совместимости.

  Также он добавляет:

  • Первоклассная поддержка виртуальных транспортов; Redis, Django ORM, SQLAlchemy, Beanstalk, MongoDB, CouchDB и in-memory.

  • Последовательная обработка ошибок с помощью интроспекции,

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

  • Сжатие сообщения (zlib, bz2, или пользовательские схемы сжатия).

  Это означает, что ghettoq больше не нужен, поскольку функциональность, которую он предоставлял, уже доступна в Celery по умолчанию. Виртуальные транспорты также более функциональны и поддерживают обмены (прямые и тематические). Транспорт Redis даже поддерживает fanout-обмены, поэтому он способен выполнять команды удаленного управления рабочими.

• Магические аргументы ключевых слов, ожидающие устаревания.

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

  Было нелегко найти способ устаревания волшебных ключевых слов-аргументов, но мы считаем, что это решение имеет смысл, и оно не будет иметь никаких негативных последствий для существующего кода.

  Путь к миру, свободному от волшебных ключевых слов и аргументов, таков:

  • модуль celery.decorators устарел, и декораторы теперь можно найти в celery.task.

  • Декораторы в celery.task по умолчанию отключают аргументы ключевых слов

  • Все примеры в документации были изменены на использование celery.task.

  Это означает, что для следующих аргументов будут включены магические аргументы ключевых слов (старый стиль):

  from celery.decorators import task
  
  @task()
  def add(x, y, **kwargs):
      print('In task %s' % kwargs['task_id'])
      return x + y
  

  И здесь не будут использоваться магические аргументы ключевых слов (новый стиль):

  from celery.task import task
  
  @task()
  def add(x, y):
      print('In task %s' % add.request.id)
      return x + y
  

  Кроме того, задачи могут не принимать аргументы с магическими ключевыми словами, установив атрибут task.accept_magic_kwargs.

  Амортизация

  Использование декораторов в celery.decorators выдает PendingDeprecationWarning с полезным сообщением, призывающим вас изменить свой код, в версии 2.4 это будет заменено на DeprecationWarning, а в версии 4.0 модуль celery.decorators будет удален и перестанет существовать.

  Аналогично, атрибут task.accept_magic_kwargs больше не будет иметь никакого эффекта, начиная с версии 4.0.

• Аргументы магического ключевого слова теперь доступны как task.request.

  Это называется контекст. Используя локальное хранилище потока, контекст содержит состояние, связанное с текущим запросом.

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

  Следующие атрибуты контекста всегда доступны:

  Магический аргумент ключевого слова	Заменить на
  kwargs[„task_id“]	self.request.id
  kwargs[„delivery_info“]	self.request.delivery_info
  kwargs[„task_retries“]	self.request.retries
  kwargs[„logfile“]	self.request.logfile
  kwargs[„loglevel“]	self.request.loglevel
  kwargs[„task_is_eager“]	self.request.is_eager
  NEW	self.request.args
  NEW	self.request.kwargs

  Кроме того, следующие методы теперь автоматически используют текущий контекст, поэтому вам больше не нужно передавать kwargs вручную:

  • task.retry

  • task.get_logger

  • task.update_state

• Eventlet поддержка.

  Это отличная новость для задач, связанных с вводом-выводом!

  Для изменения реализаций пулов используется аргумент celery worker --pool, или глобально с помощью параметра CELERYD_POOL. Это может быть полное имя класса или один из следующих псевдонимов: processes, eventlet, gevent.

  Для получения дополнительной информации см. раздел Конкурентность с Eventlet в Руководстве пользователя.

  Почему не gevent?

  Для нашей первой альтернативной реализации параллелизма мы сосредоточились на Eventlet, но есть также экспериментальный пул gevent. В нем отсутствуют некоторые функции, в частности, возможность планирования задач ETA.

  Надеюсь, что поддержка gevent будет полностью реализована к версии 2.3, но это зависит от спроса (и вклада) пользователей.

• Поддержка Python 2.4 устарела!

  Мы с радостью^H^H^H^H^H^H^H^Hsad объявляем, что это последняя версия, поддерживающая Python 2.4.

  Если вы застряли на Python 2.4, вам следует поднять шум. Жалуйтесь своим сопровождающим пакетов, сисадминам и начальникам: скажите им, что пора двигаться дальше!

  Помимо желания воспользоваться преимуществами операторов with, coroutines, условных выражений и улучшенных блоков try, кодовая база теперь содержит так много хаков и обходных путей, связанных с 2.4, что это уже не просто компромисс, а жертва.

  Если это действительно не ваш выбор, и у вас нет возможности перейти на более новую версию Python, вы можете просто продолжать использовать Celery 2.2. Важные исправления могут быть перенесены на новую версию до тех пор, пока есть интерес.

• worker: Теперь поддерживается автомасштабирование дочерних рабочих процессов.

  Опция --autoscale может использоваться для настройки минимального и максимального количества дочерних рабочих процессов:

  --autoscale=AUTOSCALE
       Enable autoscaling by providing
       max_concurrency,min_concurrency. Example:
         --autoscale=10,3 (always keep 3 processes, but grow to
        10 if necessary).
  

• Удаленная отладка заданий

  celery.contrib.rdb - это расширенная версия pdb, которая позволяет удаленно отлаживать процессы, не имеющие терминального доступа.

  Пример использования:

      from celery.contrib import rdb
      from celery.task import task
  
      @task()
      def add(x, y):
          result = x + y
          # set breakpoint
          rdb.set_trace()
          return result
  
  :func:`~celery.contrib.rdb.set_trace` sets a breakpoint at the current
  location and creates a socket you can telnet into to remotely debug
  your task.
  
  The debugger may be started by multiple processes at the same time,
  so rather than using a fixed port the debugger will search for an
  available port, starting from the base port (6900 by default).
  The base port can be changed using the environment variable
  :envvar:`CELERY_RDB_PORT`.
  
  By default the debugger will only be available from the local host,
  to enable access from the outside you have to set the environment
  variable :envvar:`CELERY_RDB_HOST`.
  
  When the worker encounters your breakpoint it will log the following
  information::
  
      [INFO/MainProcess] Received task:
          tasks.add[d7261c71-4962-47e5-b342-2448bedd20e8]
      [WARNING/PoolWorker-1] Remote Debugger:6900:
          Please telnet 127.0.0.1 6900.  Type `exit` in session to continue.
      [2011-01-18 14:25:44,119: WARNING/PoolWorker-1] Remote Debugger:6900:
          Waiting for client...
  
  If you telnet the port specified you'll be presented
  with a ``pdb`` shell:
  
  .. code-block:: console
  
      $ telnet localhost 6900
      Connected to localhost.
      Escape character is '^]'.
      > /opt/devel/demoapp/tasks.py(128)add()
      -> return result
      (Pdb)
  
  Enter ``help`` to get a list of available commands,
  It may be a good idea to read the `Python Debugger Manual`_ if
  you have never used `pdb` before.
  

• События теперь являются преходящими и используют обмен темами (вместо прямого).

  Настройки CELERYD_EVENT_EXCHANGE, CELERYD_EVENT_ROUTING_KEY, CELERYD_EVENT_EXCHANGE_TYPE больше не используются.

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

  Ключом маршрутизации события является тип события (например, worker.started, worker.heartbeat, task.succeeded и т.д.). Это означает, что потребитель может отфильтровать определенные типы, чтобы получать уведомления только о тех событиях, которые ему важны.

  Каждый потребитель будет создавать уникальную очередь, то есть, по сути, это широковещательный обмен.

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

  Примечание

  Обмен событиями был переименован из "celeryevent" в "celeryev", чтобы он не сталкивался с более старыми версиями.

  Если вы хотите удалить старый обмен, вы можете сделать это, выполнив следующую команду:

  $ camqadm exchange.delete celeryevent
  

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

  Параметры конфигурации должны появляться после последнего аргумента, разделенные двумя тире:

  $ celery worker -l info -I tasks -- broker.host=localhost broker.vhost=/app
  

• Конфигурация теперь является псевдонимом оригинальной конфигурации, поэтому изменения в оригинале будут отражаться в Celery во время выполнения.

• celery.conf был устаревшим, и изменение celery.conf.ALWAYS_EAGER больше не будет иметь никакого эффекта.

  Конфигурация по умолчанию теперь доступна в модуле celery.app.defaults. Доступные параметры конфигурации и их типы теперь могут быть проанализированы.

• Команды удаленного управления теперь предоставляются kombu.pidbox, общим почтовым ящиком процесса.

• Внутренний модуль celery.worker.listener был переименован в celery.worker.consumer, а .CarrotListener стал .Consumer.

• Ранее устаревшие модули celery.models и celery.management.commands теперь удалены в соответствии с временной линией устаревания.

• [Безопасность: Низкая серьезность] Удалены celery.task.RemoteExecuteTask и

  сопутствующие функции: dmap, dmap_async и execute_remote.

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

  Если вам действительно нужна эта функциональность, то вам придется добавить ее в свой собственный проект.

• [Безопасность: Низкая серьезность] Команда stats больше не передает пароль брокера.

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

Новости¶

• Внутренний модуль celery.task.builtins был удален.

• Модуль celery.task.schedules устарел, вместо него следует использовать celery.schedules.

  Например, если у вас есть:

  from celery.task.schedules import crontab
  

  Вы должны заменить это на:

  from celery.schedules import crontab
  

  Модуль необходимо переименовать, потому что должна быть возможность импортировать расписания без импорта модуля celery.task.

• Следующие функции были устаревшими и планируются к удалению в версии 2.3:

  • celery.execute.apply_async

    Вместо этого используйте task.apply_async().

  • celery.execute.apply

    Вместо этого используйте task.apply().

  • celery.execute.delay_task

    Вместо этого используйте registry.tasks[name].delay().

• Импорт TaskSet из celery.task.base теперь устарел.

  Вы должны использовать:

  >>> from celery.task import TaskSet
  

  вместо этого.

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

  • active_queues

    Возвращает объявления очередей, которые в данный момент потребляет рабочий.

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

  По умолчанию он отключен, но может быть включен с помощью параметра CELERY_TASK_PUBLISH_RETRY, а также настроен с помощью параметра CELERY_TASK_PUBLISH_RETRY_POLICY.

  Кроме того, ключевые аргументы retry и retry_policy были добавлены в Task.apply_async.

  Примечание

  Использование аргумента retry в apply_async требует, чтобы вы обрабатывали издателя/соединение вручную.

• Классы периодических задач (@periodic_task/PeriodicTask) не будут устаревшими, как было указано ранее в исходном коде.

  Но рекомендуется использовать более гибкую настройку CELERYBEAT_SCHEDULE.

• Встроенная поддержка демонизации рабочего с помощью celery multi больше не является экспериментальной и считается производственным качеством.

  Смотрите Общие init-скрипты, если вы хотите использовать новые общие скрипты init.

• Добавлена поддержка сжатия сообщений с помощью параметра CELERY_MESSAGE_COMPRESSION или аргумента compression в apply_async. Это также может быть установлено с помощью маршрутизаторов.

• рабочий: Теперь регистрирует стек-трейс всех потоков при получении команды

  Сигнал SIGUSR1 (не работает на CPython 2.4, Windows или Jython).

  Вдохновлено https://gist.github.com/737056

• Теперь можно удаленно завершить/убить рабочий процесс, обрабатывающий задание.

  Команда удаленного управления revoke теперь поддерживает аргумент terminate Сигнал по умолчанию - TERM, но может быть задан с помощью аргумента signal. Signal может быть заглавным именем любого сигнала, определенного в модуле signal в стандартной библиотеке Python.

  Завершение задания также отзывает его.

  Пример:

  >>> from celery.task.control import revoke
  
  >>> revoke(task_id, terminate=True)
  >>> revoke(task_id, terminate=True, signal='KILL')
  >>> revoke(task_id, terminate=True, signal='SIGKILL')
  

• TaskSetResult.join_native: Оптимизированная для бэкенда версия join().

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

  Пока что поддерживается только бэкенд результатов AMQP. Поддержка Memcached и Redis может быть добавлена позже.

• Улучшены реализации TaskSetResult.join и AsyncResult.wait.

  Ключевое слово interval было добавлено в оба аргумента, чтобы можно было указать интервал опроса (по умолчанию интервал составляет 0,5 секунды).

  Ключевой аргумент propagate был добавлен к result.wait(), ошибки будут возвращаться, а не подниматься, если установлено значение False.

  Предупреждение

  Вам следует уменьшить интервал опроса при использовании бэкенда результатов базы данных, так как частый опрос может привести к высокой нагрузке на базу данных.

• PID дочернего рабочего процесса, принимающего задание, теперь отправляется в виде поля с событием task-started.

• Следующие поля были добавлены ко всем событиям в классе worker:

  • sw_ident: Имя рабочего программного обеспечения (например, "py-celery").

  • sw_ver: Версия программного обеспечения (например, 2.2.0).

  • sw_sys: Операционная система (например, Linux, Windows, Darwin).

• Для большей точности при расчете длительности задачи используется время начала, сообщаемое рабочим процессом мультипроцессинга.

  Ранее использовалось время, сообщаемое обратным вызовом accept.

• celerybeat: Новая встроенная поддержка демонизации с помощью –detach.

  вариант.

• celeryev: Новая встроенная поддержка демонизации с помощью –detach.

  вариант.

• TaskSet.apply_async: Теперь поддерживает пользовательские издатели с помощью аргумента publisher.

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

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

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

  запланированные задачи.

• Теперь модуль конфигурации и используемый загрузчик можно указать в командной строке.

  Например:

  $ celery worker --config=celeryconfig.py --loader=myloader.Loader
  

• Добавлены сигналы: beat_init и beat_embedded_init.

  • celery.signals.beat_init

    Отправляется при запуске celerybeat (автономном или встроенном). Отправителем является экземпляр celery.beat.Service.

  • celery.signals.beat_embedded_init

    Отправляется в дополнение к сигналу beat_init, когда celerybeat запускается как встроенный процесс. Отправителем является экземпляр celery.beat.Service.

• Бэкенд результатов Redis: Удалены устаревшие настройки REDIS_TIMEOUT и REDIS_CONNECT_RETRY.

• CentOS init-script для celery worker теперь доступен в extra/centos.

• Теперь зависит от pyparsing версии 1.5.0 или выше.

  Сообщалось о проблемах при использовании Celery с pyparsing 1.4.x, поэтому, пожалуйста, обновите его до последней версии.

• Написано много новых юнит-тестов, теперь общее покрытие составляет 95%.

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

• celeryev Curses Monitor: улучшена обработка изменения размера и компоновка пользовательского интерфейса (Выпуск #274 + Выпуск #276)

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

  то рабочий покажет в журнале полную трассировку этих ошибок.

• Бэкенд AMQP: Больше не удаляет очередь результатов после успешного опроса, так как это должно обрабатываться настройкой CELERY_AMQP_TASK_RESULT_EXPIRES.

• Бэкенд AMQP: Теперь обеспечивает объявление очередей перед опросом результатов.

• Windows: worker: Показать ошибку при запуске с опцией -B.

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

• Windows: Утилиты больше не выводят цветовые коды ANSI в Windows

• camqadm: Теперь правильно обрабатывает Control-c, просто завершая работу, вместо того, чтобы показывать запутанный traceback.

• Windows: Все тесты теперь проходят под Windows.

• Удалите каталог bin/ и раздел scripts из :file:`setup.py.

  Это означает, что теперь мы полностью полагаемся на точки входа setuptools.

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

• Jython: worker теперь работает на Jython с использованием пула потоков.

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

• PyPy: worker теперь работает на PyPy.

  Он работает без пула, поэтому для параллельного выполнения необходимо запустить несколько экземпляров (например, используя multi).

  К сожалению, первоначальный бенчмарк показывает снижение производительности на 30% на pypy-1.4.1 + JIT. Мы хотели бы выяснить причину этого, так что следите за новостями.

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

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

  from celery import current_app
  
  # Global pool
  pool = current_app().amqp.PublisherPool(limit=10)
  
  def my_view(request):
      with pool.acquire() as publisher:
          add.apply_async((2, 2), publisher=publisher, retry=True)