История изменений для Celery 2.3¶
2.3.4¶
- дата выхода:
2011-11-25 04:00 вечера по Гринвичу
- релиз на:
Спросите Солема
Исправления в системе безопасности¶
[Безопасность: CELERYSA-0001] Демоны устанавливали эффективные, а не реальные идентификаторы, когда использовались аргументы
--uid
/--gid
для celery multi, celeryd_detach, celery beat и celery events.Это означает, что привилегии не были сброшены должным образом, и что позже можно будет восстановить привилегии супервизора.
Исправления¶
Перенесено исправление для #455 из версии 2.4 в версию 2.3.
StateDB не была сохранена при выключении.
Исправляет ситуацию, когда рабочий иногда зависал при превышении лимита жесткого времени.
2.3.3¶
- дата выхода:
2011-16-09 05:00 p.m. BST
- релиз на:
Мгер Мовсисян
Патчирование обезьяны
sys.stdout
могло привести к аварийному завершению работы, если заменяющий объект не определялisatty()
(проблема #477).Опция
CELERYD
в/etc/default/celeryd
не должна использоваться с общими init-скриптами.
2.3.2¶
- дата выхода:
2011-10-07 05:00 вечера BST
- релиз на:
Спросите Солема
Новости¶
Улучшенное руководство по внесению вклада.
Если вы хотите внести свой вклад в Celery, вам следует прочитать Contributing Gudie.
Мы ищем участников с любым уровнем подготовки, так что не сомневайтесь!
Теперь зависит от Kombu 1.3.1
Task.request
теперь содержит имя текущего рабочего хоста (выпуск #460).Доступно как
task.request.hostname
.- Теперь подклассам приложений стало проще расширять способ маринования.
(см.
celery.app.AppPickler
).
Исправления¶
purge/discard_all работал некорректно (проблема #455).
Раскраска сообщений журнала не очень хорошо обрабатывала данные, отличные от ASCII (проблема #427).
[Windows] мультипроцессорный пул пытался импортировать
os.kill
, хотя там этого нет (проблема #450).Исправление случая, когда рабочий мог не реагировать на запросы из-за того, что задания превышали жесткий лимит времени.
Событие
task-sent
отсутствовало в ссылке на событие.ResultSet.iterate
теперь возвращает результаты по мере их завершения (выпуск #459).Раньше такого не было, хотя в документации указано, что это ожидаемое поведение.
Повторные вызовы больше не будут выполняться при прямом вызове задач (с использованием
__call__
).Вместо этого исключение, переданное в
retry
, будет повторно поднято.Eventlet больше не падает, если включен автомасштаб.
увеличение и уменьшение пулов эвентов по-прежнему не поддерживается.
py24
цель удалена изtox.ini
.
2.3.1¶
- дата выхода:
2011-08-07 08:00 вечера BST
- релиз на:
Спросите Солема
Исправления¶
Настройка
CELERY_AMQP_TASK_RESULT_EXPIRES
не работала, что приводило к ошибке, связанной с AMQP, о невозможности сериализации плавающих значений при попытке публикации состояний задачи (проблема #446).
2.3.0¶
- дата выхода:
2011-08-05 12:00 BST
- проверено:
CPython: 2.5, 2.6, 2.7; PyPy: 1.5; Jython: 2.5.2
- релиз на:
Спросите Солема
Важные замечания¶
Теперь требуется Kombu 1.2.1
Результаты теперь отключены по умолчанию.
Бэкенд AMQP не подходил по умолчанию, поскольку часто пользователи не получали результаты, что приводило к образованию тысяч очередей.
Хотя очереди могут быть настроены на истечение срока действия, если они не используются, не было возможности включить это по умолчанию, поскольку это было доступно только в последних версиях RabbitMQ (2.1.1+).
С этим изменением включение бэкенда результата будет осознанным выбором, что, надеюсь, заставит пользователя прочитать документацию и знать о любых общих подводных камнях, связанных с конкретным бэкендом.
Бэкенд по умолчанию теперь является фиктивным бэкендом (
celery.backends.base.DisabledBackend
). Сохранение состояния - это просто отказ, а AsyncResult.wait(), .result, .state и т.д. будут вызывать предупреждениеNotImplementedError
, говорящее пользователю о необходимости настроить бэкенд результата.За помощью в выборе бэкенда обращайтесь к Бэкенды результатов.
Если вы зависите от предыдущего бэкенда по умолчанию, которым был бэкенд AMQP, то вы должны установить это явно перед обновлением:
CELERY_RESULT_BACKEND = 'amqp'
Примечание
Для пользователей django-celery по умолчанию по-прежнему используется бэкенд
database
, и результаты не отключены по умолчанию.Инит-скрипты Debian были отменены в пользу инит-скриптов generic-init.d.
Кроме того, были добавлены общие init-скрипты для
celerybeat
иceleryev
.
Новости¶
Автоматическая поддержка пула соединений.
Пул используется всем, что требует соединения с брокером, например, вызов задач, отправка широковещательных команд, получение результатов с помощью бэкенда результатов AMQP и так далее.
По умолчанию пул отключен, но вы можете включить его, настроив параметр
BROKER_POOL_LIMIT
:BROKER_POOL_LIMIT = 10
Ограничение 10 означает, что одновременно могут сосуществовать не более 10 соединений. В однопоточной среде будет использоваться только одно соединение, но в параллельной среде (потоки, гринлеты и т.д., но не процессы), когда лимит превышен, любая попытка получить соединение будет блокировать поток и ждать освобождения соединения. Это следует учитывать при выборе лимита.
Лимит
None
или 0 означает отсутствие лимита, и соединения будут устанавливаться и закрываться каждый раз.Представляем аккорды (обратные вызовы набора задач).
Аккорд - это задача, которая выполняется только после завершения выполнения всех задач в наборе задач. Это модный термин для «обратных вызовов набора задач», заимствованный из Cω).
Он работает со всеми бэкендами результатов, но наилучшая реализация в настоящее время обеспечивается бэкендом результатов Redis.
Вот пример аккорда:
>>> chord(add.subtask((i, i)) ... for i in xrange(100))(tsum.subtask()).get() 9900
Пожалуйста, прочитайте Chords section in the user guide, если вы хотите узнать больше.
Теперь для отдельных задач можно устанавливать временные ограничения.
Чтобы установить мягкие и жесткие временные ограничения для задачи, используйте атрибуты
time_limit
и << 1 >>>:import time @task(time_limit=60, soft_time_limit=30) def sleeptask(seconds): time.sleep(seconds)
Если атрибуты не заданы, то будут использоваться временные ограничения по умолчанию для рабочих.
Новое в этой версии: вы также можете изменить временные ограничения для задачи во время выполнения, используя команду
time_limit()
дистанционного управления:>>> from celery.task import control >>> control.time_limit('tasks.sleeptask', ... soft=60, hard=120, reply=True) [{'worker1.example.com': {'ok': 'time limits set successfully'}}]
Затронуты будут только те задания, которые начали выполняться после изменения лимита времени.
Примечание
Мягкие временные ограничения все равно не будут работать на Windows или других платформах, не имеющих сигнала
SIGUSR1
.- Имена директив конфигурации бэкенда Redis изменены, чтобы включать в себя
CELERY_
префикс.Старое название настройки
Заменить на
REDIS_HOST
CELERY_REDIS_HOST
REDIS_PORT
CELERY_REDIS_PORT
REDIS_DB
CELERY_REDIS_DB
REDIS_PASSWORD
CELERY_REDIS_PASSWORD
Старые названия все еще поддерживаются, но ожидают своего устаревания.
PyPy: Используемая по умолчанию реализация пула теперь является многопроцессорной, если выполняется на PyPy 1.5.
multi: теперь поддерживает опции «pass through».
Опции pass through облегчают использование Celery без конфигурационного файла или просто добавление опций в последний момент в командной строке.
Пример использования:
$ celery multi start 4 -c 2 -- broker.host=amqp.example.com \ broker.vhost=/ \ celery.disable_rate_limits=yes
celerybeat
: Теперь повторно пытается установить соединение (проблема #419).celeryctl
: Новая командаlist bindings
.Перечисляет текущие или все доступные привязки, в зависимости от используемого транспорта брокера.
Сердцебиение теперь отправляется каждые 30 секунд (ранее - каждые 2 минуты).
ResultSet.join_native()
иiter_native()
теперь поддерживаются бэкендами результатов Redis и Cache.Это оптимизированная версия
join()
, использующая способность базового бэкенда получать несколько результатов одновременно.Теперь можно использовать SSL при отправке сообщений об ошибках, включив параметр
EMAIL_USE_SSL
.events.default_dispatcher()
: Контекстный менеджер для легкого получения экземпляра диспетчера событий с помощью пула соединений.Ошибки импорта в модуле конфигурации больше не будут замалчиваться.
ResultSet.iterate: Теперь поддерживает аргументы
timeout
,propagate
иinterval
.with_default_connection
->with default_connection
TaskPool.apply_async: Аргументы ключевых слов
callbacks
иerrbacks
были переименованы вcallback
иerrback
и принимают одно скалярное значение вместо списка.Больше не распространяются ошибки, возникающие при очистке процесса (проблема №365)
Добавлено
TaskSetResult.delete()
, которое удаляет ранее сохраненный результат набора задач.celerybeat
теперь синхронизируется каждые 3 минуты, а не только при выключении (проблема #382).Мониторы теперь правильно обрабатывают неизвестные события, поэтому отображаются события, заданные пользователем.
Завершение задачи в Windows теперь также завершает все дочерние процессы задачи (выпуск #384).
worker:
-I|--include
опция теперь всегда ищет текущий каталог для импорта указанных модулей.Бэкенд Cassandra: Теперь результаты истекают с использованием TTL.
Набор функциональных тестов в
funtests
теперь действительно работает правильно и проходит тесты.
Исправления¶
celeryev
пытался создать pid-файл дважды.celery.contrib.batches: Исправлена проблема, при которой задания не выполнялись молча (проблема #393).
Исправлена проблема, при которой регистрация объектов выдавала сообщение «<Непредставимо», даже если объекты были.
CELERY_TASK_ERROR_WHITE_LIST
теперь правильно инициализируется во всех загрузчиках.celeryd_detach
теперь проходит через конфигурацию командной строки.Команда удаленного управления
add_consumer
теперь ничего не делает, если очередь уже потребляется.