Celery2.0の変更履歴

2.0.3
- 修正
- ドキュメンテーション
2.0.2
2.0.1
2.0.0

2.0.3

発売日: 2010-08-27 12:00 pm CEST
リリースバイ: ソレムに聞く

修正

ワーカー：コンシューマーを閉じるときに発生する接続エラーを適切に処理します。
ワーカー：接続がダウンした場合にイベントがバッファリングされ、接続が再確立されたときに送信されるようになりました。
：pypi： `mailer` パッケージに依存しなくなりました。

このパッケージは、 django-mailer と名前空間が衝突したため、その機能が置き換えられました。
Redis結果バックエンド：ドキュメントのタイプミス：Redisにはデータベース名はありませんが、データベース番号があります。デフォルトのデータベースは0になりました。
inspect： registerd_tasks は、タイプミスのために無効なコマンドを要求していました。

問題＃170を参照してください。
：setting： `CELERY_ROUTES` ：2つをマージするときに、ルートで定義された値が：setting：` CELERY_QUEUES` で定義された値よりも優先されるようになりました。
次の設定で：
CELERY_QUEUES = {'cpubound': {'exchange': 'cpubound', 'routing_key': 'cpubound'}} CELERY_ROUTES = {'tasks.add': {'queue': 'cpubound', 'routing_key': 'tasks.add', 'serializer': 'json'}}
tasks.add の最終的なルーティングオプションは次のようになります。
{'exchange': 'cpubound', 'routing_key': 'tasks.add', 'serializer': 'json'}
以前はそうではありませんでした。：setting： `CELERY_QUEUES` の値が優先されます。
：setting： `CELERY_TASK_ERROR_WHITELIST` の値が反復可能でない場合、ワーカーがクラッシュしました
apply()： kwargs ['task_id'] が常に設定されていることを確認してください。
AsyncResult.traceback ：トレースバックが欠落している場合にKeyErrorを上げる代わりに、Noneを返すようになりました。
inspect：宛先が指定されていない場合、返信は正しく機能しませんでした。
カスタム状態の結果/メタデータを保存できるようになりました。
ワーカー：タスクエラーメールの送信が失敗した場合に警告が発行されるようになりました。
celeryev：ターミナルウィンドウのサイズが変更されても、Cursesモニターがクラッシュしなくなりました。

問題＃160を参照してください。
ワーカー：macOSでは、スレッド化されたプロセスで os.exec * を実行することはできません。

これはSIGHUPリスタートハンドラーを壊し、macOSで無効になり、代わりに警告を発します。

問題＃152を参照してください。
celery.execute.trace： raise（str）を適切に処理します。これは、Python2.4でも引き続き許可されています。

問題＃175を参照してください。
macOSで使用されるプロキシ自動検出が原因で、macOSの定期的なタスクでurllib2を使用するとクラッシュしました。

これは、回避策を使用することで修正されました。問題＃143を参照してください。
Debian init-scripts：コマンドはサブシェルで実行すべきではありません

問題＃163を参照してください。
Debian init-scripts：celerydプログラムの絶対パスを使用して、統計を許可します

問題＃162を参照してください。

ドキュメンテーション

入門/ブローカーインストール：タイプミスを修正

set_permissions“” -> set_permissions“。*” 。
タスクユーザーガイド：データベーストランザクションに関するセクションを追加しました。

問題＃169を参照してください。
ルーティングユーザーガイド：タイプミス「フィード」を修正：-> {「キュー」：「フィード」} 。

問題＃169を参照してください。
：setting： `CELERYD_CONCURRENCY` および：setting：` CELERYD_PREFETCH_MULTIPLIER` 設定のデフォルト値を文書化しました。
タスクユーザーガイド：サブタスクの例のタイプミスを修正
celery.signals：文書化されたworker_process_init。
デーモン化クックブック： / etc / default / celeryd にDJANGO_SETTINGS_MODULEをエクスポートする必要があります。
スタックオーバーフローからいくつかのFAQを追加しました
デーモン化クックブック：タイプミス CELERYD_LOGFILE / CELERYD_PIDFILE を修正しました

CELERYD_LOG_FILE / CELERYD_PID_FILE へ

また、init-scriptsのトラブルシューティングセクションを追加しました。

2.0.2

発売日: 2010-07-22 11:31 am CEST
リリースバイ: ソレムに聞く

ルート：dictルート構文を使用すると、タスクの交換が消えて、タスクがルーティングできなくなる可能性があります。

問題＃158を参照してください。
テストスイートがPython2.4に合格するようになりました
現在のディレクトリでceleryconfigを使用するために、 PYTHONPATH =。と入力する必要がなくなりました。

これは、構成モジュールをロードするときに現在のディレクトリが sys.path にあることを確認するデフォルトのローダーによって実現されます。 sys.path は、ロード後に元の状態にリセットされます。

ユーザーが知らないうちに現在の作業ディレクトリを sys.path に追加すると、セキュリティ上の問題が発生する可能性があります。これは、誰かが任意のコマンドを実行するPythonモジュールをユーザーディレクトリにドロップできることを意味します。これが元々の理由でしたが、構成モジュールのロード時にのみを実行した場合、この動作は構成モジュールにインポートされたモジュールにのみ適用されることを意味します。これは適切な妥協案だと思います。（とにかく PYTHONPATH =。を明示的に設定するよりも確かに優れています）
実験的なCassandraバックエンドが追加されました。
ワーカー：SIGHUPハンドラーが誤ってワーカープールプロセスに伝播されました。

：sha： `7a7c44e39344789f11b5346e9cc8340f5fe4846c` と組み合わせると、ターミナルウィンドウが閉じられたときに、各子プロセスが新しいワーカーインスタンスを開始します：/
ワーカー：端末から実行している場合は、SIGHUPハンドラーをインストールしないでください。

これにより、ターミナルを閉じるときにワーカーがバックグラウンドで起動される問題が修正されます。
ワーカー：シャットダウン時にスレッドに参加するようになりました。

問題＃152を参照してください。
分解のテスト： atexit を使用せず、代わりにnoseの teardown（）機能を使用します。

問題＃154を参照してください。
Debianワーカーのinit-script：停止が正しく機能するようになりました。
タスクロガー： warn メソッドが追加されました（ warning の同義語）
エラーメールを送信するエラーのホワイトリストを定義できるようになりました。
例：
CELERY_TASK_ERROR_WHITELIST = ('myapp.MalformedInputError',)
問題＃153を参照してください。
ワーカー：ETAフィールドの解析中に、 time.mktime でオーバーフロー例外を処理するようになりました。
LoggerWrapper：無限ループを作っているstderr / stdoutにログインしているロガーを検出してみてください。

追加celery.task.control.inspect：実行中のワーカーを検査します。

例：

# Inspect a single worker
>>> i = inspect('myworker.example.com')

# Inspect several workers
>>> i = inspect(['myworker.example.com', 'myworker2.example.com'])

# Inspect all workers consuming on this vhost.
>>> i = inspect()

### Methods

# Get currently executing tasks
>>> i.active()

# Get currently reserved tasks
>>> i.reserved()

# Get the current ETA schedule
>>> i.scheduled()

# Worker statistics and info
>>> i.stats()

# List of currently revoked tasks
>>> i.revoked()

# List of registered tasks
>>> i.registered_tasks()

リモートコントロールコマンド dump_active / dump_reserved / dump_schedule は、詳細なタスク要求で応答するようになりました。

要求されたタスクの元の引数とフィールドが含まれています。

さらに、リモートコントロールコマンド set_loglevel が追加されました。これは、メインプロセスのログレベルのみを変更します。
ワーカー制御コマンドの実行でエラーがキャッチされ、応答で文字列表現が返されるようになりました。
機能テストスイートが追加されました

celery.tests.functional.caseには、機能テストで使用するために、組み込みワーカープロセスを開始および停止するユーティリティが含まれています。

2.0.1

発売日: 2010-07-09 03:02 pm CEST
リリースバイ: ソレムに聞く

multiprocessing.pool：エンコードエラーを処理するようになり、ピクルスエラーがワーカープロセスをクラッシュさせないようになりました。
リモートコントロールコマンドの応答は、RabbitMQ1.8.0のより厳密な同等性チェックでは機能しませんでした。
すでにこの問題が発生している場合は、宣言を削除する必要があります。
$ camqadm exchange.delete celerycrq
また：
$ python manage.py camqadm exchange.delete celerycrq
1秒あたり1つのタスクしか実行できないようにするETAスケジューラーに潜入したバグ（！）

スケジューラーは反復間でスリープするため、CPUをあまり消費しません。スケジュールされたアイテムのリストを時間でソートして保持し、各反復で、最も近い期限のあるアイテムの残りの時間スリープします。 ETAタスクがない場合、最小時間（デフォルトでは1秒）スリープします。

ここにバグが潜入し、スケジュールされたすべてのタスクで1秒間スリープ状態になりました。これは修正されたので、ホットナイフのようなタスクをバターに通す必要があります。

さらに、最小スリープ間隔を制御するための新しい設定が追加されました。：setting： `CELERYD_ETA_SCHEDULER_PRECISION` 。これに適した値は、必要な精度に応じて、0から1の間の浮動小数点数です。値0.8は、タスクのETAが満たされたときに、タスクが準備完了キューに移動されるまでに最大0.8秒かかることを意味します。
プール：スーパーバイザーはセマフォを解放しませんでした。

すべてのワーカーが途中で終了した場合、これはデッドロックにつながります。
Pythonバージョンのtrove分類子を追加しました：2.4、2.5、2.6、2.7
テストはPython2.7に合格しました。
Task .__ reduce__：タスクデコレータを使用して作成されたタスクをpickle化できるようになりました。
setup.py：：pypi： `nose` が tests_require に追加されました。
PickleはSQLAlchemy0.5.xで動作するはずです
Jan Henrik Helmersによる新しいホームページデザイン： http://celeryproject.org
Armin Ronacherによる新しいSphinxテーマ： http://docs.celeryproject.org/
ドキュメントのHTMLレンダリングに表示される「pending_xref」エラーを修正しました。どうやらこれはSphinx1.0b2の新しい変更が原因だったようです。
：setting： `CELERY_ROUTES` のルータークラスが遅延インポートされるようになりました。

Celery環境もロードするモジュールにルータークラスをインポートすると、循環依存が発生します。これは、環境のセットアップ後に必要に応じてインポートすることで解決されます。
：setting： `CELERY_ROUTES` は、単一のdictに設定されていると壊れていました。
ドキュメントのこの例は、再び機能するはずです。
CELERY_ROUTES = {'feed.tasks.import_feed': 'feeds'}
CREATE_MISSING_QUEUES はapply_asyncによって尊重されませんでした。

新しいリモートコントロールコマンド： stats

プールプロセスID、タイプごとに実行されたタスクの総数など、ワーカーに関する情報をダンプします。

返信例：
[{'worker.local':
     'total': {'tasks.sleeptask': 6},
     'pool': {'timeouts': [None, None],
              'processes': [60376, 60377],
              'max-concurrency': 2,
              'max-tasks-per-child': None,
              'put-guarded-by-semaphore': True}}]

新しいリモートコントロールコマンド： dump_active

ワーカーによって現在実行されているタスクのリストを提供します。デフォルトでは、JSONでエンコードできない引数がある場合、引数はreprを介して渡されます。引数がJSONセーフであることがわかっている場合は、引数 safe = True を渡すことができます。

返信例：
>>> broadcast('dump_active', arguments={'safe': False}, reply=True)
[{'worker.local': [
    {'args': '(1,)',
     'time_start': 1278580542.6300001,
     'name': 'tasks.sleeptask',
     'delivery_info': {
         'consumer_tag': '30',
         'routing_key': 'celery',
         'exchange': 'celery'},
     'hostname': 'casper.local',
     'acknowledged': True,
     'kwargs': '{}',
     'id': '802e93e9-e470-47ed-b913-06de8510aca2',
    }
]}]

永続的な取り消しの実験的なサポートが追加されました。
ワーカーに対して -S | –statedb 引数を使用して、ワーカーを有効にします。
$ celeryd --statedb=/var/run/celeryd
これはファイル /var/run/celeryd.db を使用します。 shelve モジュールが自動的に .db サフィックスを追加するためです。

2.0.0

発売日: 2010-07-02 02:30 pm CEST
リリースバイ: ソレムに聞く

序文

Celery 2.0には、下位互換性のない変更が含まれています。最も重要なのは、Djangoの依存関係が削除されたため、CeleryはDjangoをすぐにサポートしなくなり、代わりに：pypi： `django-celery` [ X237X]。

下位互換性を壊して申し訳ありませんが、アップグレードを失った時間を埋め合わせるための多くの新しいエキサイティングな機能もあります。ニュースセクションを必ずお読みください。

かなり多くの潜在的なユーザーがDjangoの依存関係に腹を立てているので、これはPythonコミュニティでも広く採用されるチャンスかもしれません。

すべての貢献者、テスター、ユーザーに感謝します！

Djangoユーザー向けのアップグレード

Django統合は別のパッケージ：pypi： `django-celery` に移動されました。

アップグレードするには、：pypi： `django-celery` モジュールをインストールし、以下を変更する必要があります。
```
INSTALLED_APPS = 'celery'
```
に：
```
INSTALLED_APPS = 'djcelery'
```
mod_wsgi を使用する場合は、 .wsgi ファイルに次の行を追加する必要があります。
import os os.environ['CELERY_LOADER'] = 'django'

次のモジュールはに移動されました：pypi： `django-celery` ：

モジュール名

と置換する

celery.models

djcelery.models

celery.managers

djcelery.managers

celery.views

djcelery.views

celery.urls

djcelery.urls

celery.management

djcelery.management

celery.loaders.djangoapp

djcelery.loaders

celery.backends.database

djcelery.backends.database

celery.backends.cache

djcelery.backends.cache

djceleryをインポートすると、Djangoローダーを使用するようにCeleryが自動的にセットアップされます。ローダ。これを行うには、 CELERY_LOADER環境変数を「django」に設定します（ローダーが既に設定されている場合は変更されません）。

Djangoローダーを使用すると、「データベース」と「キャッシュ」の結果バックエンドエイリアスは、組み込みのバックエンドではなくdjceleryバックエンドを指し、構成はDjango設定から読み取られます。

他の人のためにアップグレードする

データベース結果バックエンド

データベース結果バックエンドは、DjangoORMの代わりに SQLAlchemy を使用するようになりました。サポートされているデータベースの表については、サポートされているデータベースを参照してください。

DATABASE _ * 設定は、：setting： `CELERY_RESULT_DBURI` という1つの設定に置き換えられました。ここでの値は SQLAlchemy接続文字列である必要があります。いくつかの例は次のとおりです。

# sqlite (filename)
CELERY_RESULT_DBURI = 'sqlite:///celerydb.sqlite'

# mysql
CELERY_RESULT_DBURI = 'mysql://scott:tiger@localhost/foo'

# postgresql
CELERY_RESULT_DBURI = 'postgresql://scott:tiger@localhost/mydatabase'

# oracle
CELERY_RESULT_DBURI = 'oracle://scott:[email protected]:1521/sidname'

接続文字列の詳細については、 SQLAlchemy接続文字列を参照してください。

追加のSQLAlchemyデータベースエンジンオプションを指定するには、：setting： `CELERY_RESULT_ENGINE_OPTIONS` 設定を使用できます。

# echo enables verbose logging from SQLAlchemy.
CELERY_RESULT_ENGINE_OPTIONS = {'echo': True}

結果のバックエンドをキャッシュする

キャッシュ結果バックエンドはDjangoキャッシュフレームワークを使用しなくなりましたが、ほとんど同じ構成構文をサポートしています。

CELERY_CACHE_BACKEND = 'memcached://A.example.com:11211;B.example.com'

キャッシュバックエンドを使用するには、：pypi： `pylibmc` または：pypi：` python-memcached` ライブラリがインストールされている必要があり、前者が最良の選択と見なされます。

サポートバックエンドタイプは memcached：// と memory：// であり、Djangoが提供する他のバックエンドをサポートする必要性は感じていません。

後方互換性のない変更

デフォルト（python）ローダーは、ImportErrorを発生させる代わりに、 celeryconfig.py が欠落している場合に警告を出力するようになりました。
構成がセットアップされていない場合、ワーカーは@ImproperlyConfiguredを発生させます。これにより、動作する構成がなくても、 –help などを使用できるようになります。

また、これにより、構成せずにCeleryのクライアント側を使用できるようになります。
>>> from carrot.connection import BrokerConnection >>> conn = BrokerConnection('localhost', 'guest', 'guest', '/') >>> from celery.execute import send_task >>> r = send_task('celery.ping', args=(), kwargs={}, connection=conn) >>> from celery.backends.amqp import AMQPBackend >>> r.backend = AMQPBackend(connection=conn) >>> r.get() 'pong'

次の非推奨設定が削除されました（ Celery非推奨タイムラインでスケジュールされているとおり）。

設定名

と置換する

CELERY_AMQP_CONSUMER_QUEUES

CELERY_QUEUES

CELERY_AMQP_EXCHANGE

CELERY_DEFAULT_EXCHANGE

CELERY_AMQP_EXCHANGE_TYPE

CELERY_DEFAULT_EXCHANGE_TYPE

CELERY_AMQP_CONSUMER_ROUTING_KEY

CELERY_QUEUES

CELERY_AMQP_PUBLISHER_ROUTING_KEY

CELERY_DEFAULT_ROUTING_KEY

celery.task.rest モジュールが削除されました。代わりに、 celery.task.http を使用してください（ Celery Deprecation Time-line でスケジュールされています）。
ローダー名のクラス名をスキップすることはできなくなりました。（ Celery Deprecation Time-line でスケジュールされているとおり）：
暗黙の Loader クラス名がサポートされなくなったと仮定すると、たとえば、次の場合に使用します。
CELERY_LOADER = 'myapp.loaders'
次のように、ローダークラス名を含める必要があります。
CELERY_LOADER = 'myapp.loaders.Loader'
：setting： `CELERY_TASK_RESULT_EXPIRES` はデフォルトで1日になりました。

以前のデフォルト設定は5日で期限切れになりました。
AMQPバックエンド： auto_delete に異なる値を使用しないでください。
このバグは、RabbitMQ 1.8.0で明らかになりました。これにより、auto_deleteと永続設定の宣言の競合が許可されなくなりました。

このバックエンドですでにCeleryを使用している場合は、前の宣言を削除する必要があります。
$ camqadm exchange.delete celeryresults
Pythonバージョン<= 2.5でcPickleの代わりにpickleを使用するようになりました
cPickleはPython <= 2.5で壊れています。

安全ではなく、誤って絶対インポートではなく相対インポートを使用するため、次に例を示します。
exceptions.KeyError
になります：
celery.exceptions.KeyError
純粋なpickleバージョンはパフォーマンスが低下しますが、古いPythonバージョンでは安全な唯一のオプションであるため、Python2.6にアップグレードすることをお勧めします。

ニュース

celeryev ：Curses CeleryMonitorおよびEventViewer。

これは、実行中のタスクをリアルタイムで確認し、準備ができたタスクのトレースバックと結果を調査できるシンプルなモニターです。また、新しいレート制限を設定したり、タスクを取り消したりすることもできます。

スクリーンショット：

thumb|none

celeryev を -d スイッチで実行すると、イベントダンパーとして機能し、受信したイベントを標準アウトにダンプするだけです。
$ celeryev -d
-> celeryev: starting capture...
casper.local [2010-06-04 10:42:07.020000] heartbeat
casper.local [2010-06-04 10:42:14.750000] task received:
    tasks.add(61a68756-27f4-4879-b816-3cf815672b0e) args=[2, 2] kwargs={}
    eta=2010-06-04T10:42:16.669290, retries=0
casper.local [2010-06-04 10:42:17.230000] task started
    tasks.add(61a68756-27f4-4879-b816-3cf815672b0e) args=[2, 2] kwargs={}
casper.local [2010-06-04 10:42:17.960000] task succeeded:
    tasks.add(61a68756-27f4-4879-b816-3cf815672b0e)
    args=[2, 2] kwargs={} result=4, runtime=0.782663106918

The fields here are, in order: *sender hostname*, *timestamp*, *event type* and
*additional event fields*.

AMQP結果バックエンド： .ready（）、 .successful（）、 .result 、 .status をサポートし、タスク状態の変化
新しいユーザーガイド：
ワーカー：標準の出力/エラーがログファイルにリダイレクトされるようになりました。

：pypi： `billiard` はCeleryリポジトリに戻されました。

モジュール名

セロリ相当

ビリヤード

celery.concurrency.processes.pool

ビリヤード。シリアル化

celery.serialization

ビリヤード.utils.functional

celery.utils.functional

：pypi： `billiard` の配布は、関心に応じて維持される場合があります。

：pypi： `carrot` > = 0.10.5に依存するようになりました
：pypi： `pyparsing` に依存するようになりました
ワーカー： –discard のエイリアスとして –purge を追加しました。
ワーカー： Control-c （SIGINT）はウォームシャットダウンを1回実行し、 Control-c を2回押すと強制終了します。
定期的なタスクで複雑なCrontab式を使用するためのサポートが追加されました。たとえば、次を使用できるようになりました。
>>> crontab(minute='*/15')
あるいは：
>>> crontab(minute='*/30', hour='8-17,1-2', day_of_week='thu-fri')
定期的なタスクを参照してください。
ワーカー：プールに新しいタスクを適用する前に、使用可能なプールプロセスを待機するようになりました。

これは、プールプロセスをすぐに受け入れることができずにプリフェッチされたタスクを適用したため、シャットダウン時に数十のタスクが終了するのを待つ必要がないことを意味します。

問題＃122を参照してください。
subtaskを使用してタスクコールバックを実行するための新しい組み込みの方法。

詳細については、 Canvas：ワークフローの設計を参照してください。
TaskSetには、いくつかのタイプのタスクを含めることができるようになりました。

TaskSetは、新しい構文を使用するようにリファクタリングされました。詳細については、 Canvas：Designing Work-flows を参照してください。

以前の構文は引き続きサポートされていますが、バージョン1.4では非推奨になります。
TaskSet failed（）の結果が正しくありませんでした。

問題＃132を参照してください。
タスククラスごとに異なるロガーを作成するようになりました。

問題＃129を参照してください。
欠落しているキュー定義が自動的に作成されるようになりました。
これは、：setting： `CELERY_CREATE_MISSING_QUEUES` 設定を使用して無効にできます。

欠落しているキューは、次のオプションで作成されます。

CELERY_QUEUES[name] = {'exchange': name, 'exchange_type': 'direct', 'routing_key': 'name}
この機能は、ワーカーへの -Q オプションを使用してルーティングを簡単に設定するために追加されました。
$ celeryd -Q video, image
詳細については、ユーザーガイドの新しいルーティングセクションを参照してください：ルーティングタスク。
新しいタスクオプション： Task.queue

設定されている場合、メッセージオプションは：setting： `CELERY_QUEUES` の対応するエントリから取得されます。 exchange 、 exchange_type 、および routing_key は無視されます
タスクのソフトおよびハード時間制限のサポートが追加されました。
追加された新しい設定：
- ：setting： `CELERYD_TASK_TIME_LIMIT`
  
  厳しい時間制限。これを超えると、タスクを処理しているワーカーが強制終了され、新しいワーカーに置き換えられます。
- ：setting： `CELERYD_TASK_SOFT_TIME_LIMIT`
  
  ソフト制限時間。これを超えると、@SoftTimeLimitExceeded例外が発生します。タスクはこれをキャッチして、たとえば、困難な時間制限が来る前にクリーンアップすることができます。
celerydへの新しいコマンドライン引数が追加されました： –time-limit および –soft-time-limit 。

何が残っていますか？

これは、シグナル（特に SIGUSR1 シグナル）をまだサポートしていないプラットフォームでは機能しません。そのため、不適合なプラットフォームでこの機能をまとめて無効にする別の機能を実装する必要があります。

また、ハードタイム制限を超えた場合、タスクの結果は TimeLimitExceeded 例外になります。
テストスイートは、ニンジンのメモリ内バックエンドを使用して、実行中のブローカーなしで合格しています。
ログ出力がカラーで利用できるようになりました。

ログレベル

色

デバッグ

青

警告

黄

致命的

赤紫色

エラー

赤

これは、ログ出力がttyの場合にのみ有効になります。：setting： `CELERYD_LOG_COLOR` 設定を使用して、この機能を明示的に有効/無効にすることができます。
タスクルータークラス（djangoマルチdbルーターなど）のサポートが追加されました
- 新しい設定：：setting： `CELERY_ROUTES`
これは、タスクを送信するときにトラバースする単一のルーターまたはルーターのリストです。このリストの辞書は、celery.routes.MapRouteインスタンスに変換されます。

例：
>>> CELERY_ROUTES = {'celery.ping': 'default', 'mytasks.add': 'cpu-bound', 'video.encode': { 'queue': 'video', 'exchange': 'media' 'routing_key': 'media.video.encode'}}
>>> CELERY_ROUTES = ('myapp.tasks.Router', {'celery.ping': 'default'})
myapp.tasks.Router は次のようになります。
class Router(object): def route_for_task(self, task, args=None, kwargs=None): if task == 'celery.ping': return 'default'
route_for_taskは、文字列またはdictを返す場合があります。文字列は、：setting： `CELERY_QUEUES` のキュー名であることを意味し、dictはカスタムルートであることを意味します。

タスクを送信するときは、ルーターが順番に参照されます。 None を返さない最初のルーターが使用するルートです。次に、メッセージオプションは、ルーター設定が優先される、見つかったルート設定とマージされます。

apply_async()に次の引数がある場合の例：
>>> Task.apply_async(immediate=False, exchange='video', ... routing_key='video.compress')
そしてルーターは以下を返します：
{'immediate': True, 'exchange': 'urgent'}
最終的なメッセージオプションは次のようになります。
>>> task.apply_async( ... immediate=True, ... exchange='urgent', ... routing_key='video.compress', ... )
（およびTaskクラスで定義されているデフォルトのメッセージオプション）
タスクが戻った後に呼び出される新しいタスクハンドラー：after_return()。
ExceptionInfoがに渡されるようになりました

on_retry() / on_failure()をeinfoキーワード引数として。
ワーカー：：setting： `CELERYD_MAX_TASKS_PER_CHILD` / celery worker --maxtasksperchildを追加しました。

プロセスが終了して新しいタスクに置き換えられる前に、プールワーカーが処理できるタスクの最大数を定義します。
取り消されたタスクは、状態：state： `REVOKED` でマークされ、 result.get（）は@TaskRevokedErrorを発生させるようになりました。
celery.task.control.ping()が期待どおりに機能するようになりました。
apply（throw = True） / ：setting： `CELERY_EAGER_PROPAGATES_EXCEPTIONS` ：熱心な実行でタスクエラーを再発生させます。
新しいシグナル：：signal： `〜celery.signals.worker_process_init` ：initのプールワーカープロセス内に送信されます。
ワーカー：celery worker -Qオプション：使用するキューのリストを指定して、他の構成済みキューを無効にする機能。
たとえば、：setting： `CELERY_QUEUES` が4つのキューを定義している場合： image 、 video 、 data 、 default [X132X ]、次のコマンドは、ワーカーが image および video キューからのみ消費するようにします。
$ celeryd -Q image,video
ワーカー： revoke 制御コマンドの新しい戻り値：
今戻ります：
{'ok': 'task $id revoked'}
Trueの代わりに。
ワーカー：リモートコントロールを使用してイベントを有効/無効にできるようになりました
使用例：
>>> from celery.task.control import broadcast >>> broadcast('enable_events') >>> broadcast('disable_events')
トップレベルのテストディレクトリを削除しました。 celery.tests.configで設定をテストします
これは、ユニットテストの実行に特別な設定が必要ないことを意味します。 celery / tests / __ init __ は、 CELERY_CONFIG_MODULEおよび CELERY_LOADER環境変数を構成するようになりました。したがって、 nosetests [X136X ]それをインポートすると、単体テスト環境がすべてセットアップされます。

テストを実行する前に、テスト要件をインストールする必要があります。
$ pip install -r requirements/test.txt
すべてのテストの実行：
$ nosetests
実行するテストの指定：
$ nosetests celery.tests.test_task
HTMLカバレッジの作成：
$ nosetests --with-coverage3
カバレッジ出力は、 celery / tests / cover / index.html にあります。
ワーカー：新しいオプション –version ：バージョン情報をダンプして終了します。

celeryd-multi：複数のワーカーを起動するためのシェルスクリプト用のツール。

いくつかの例：
10人の労働者による高度な例：
3人のワーカーが画像とビデオのキューを処理します

2人のワーカーがログレベルのDEBUGでデータキューを処理します

残りはデフォルトのキューを処理します。
$ celeryd-multi start 10 -l INFO -Q:1-3 images,video -Q:4,5:data -Q default -L:4,5 DEBUG
それぞれ3つのプロセスで10人のワーカーを開始するコマンドを取得します
$ celeryd-multi start 3 -c 3
celeryd -n celeryd1.myhost -c 3
celeryd -n celeryd2.myhost -c 3
celeryd -n celeryd3.myhost -c 3
3人の指名された労働者を始める
$ celeryd-multi start image video data -c 3
celeryd -n image.myhost -c 3
celeryd -n video.myhost -c 3
celeryd -n data.myhost -c 3
カスタムホスト名を指定する
$ celeryd-multi start 2 -n worker.example.com -c 3
celeryd -n celeryd1.worker.example.com -c 3
celeryd -n celeryd2.worker.example.com -c 3
各celerydに追加のオプションが追加されますが、範囲または単一のワーカーのオプションを変更することもできます。
3人のワーカー：2人は3プロセス、1人は10プロセス。
$ celeryd-multi start 3 -c 3 -c:1 10
celeryd -n celeryd1.myhost -c 10
celeryd -n celeryd2.myhost -c 3
celeryd -n celeryd3.myhost -c 3
名前付きワーカーのオプションを指定することもできます
$ celeryd-multi start image video data -c 3 -c:image 10
celeryd -n image.myhost -c 10
celeryd -n video.myhost -c 3
celeryd -n data.myhost -c 3
オプション内のワーカーの範囲とリストも許可されます：（-c:1-3は-c:1,2,3と書くこともできます）
$ celeryd-multi start 5 -c 3  -c:1-3 10
celeryd-multi -n celeryd1.myhost -c 10
celeryd-multi -n celeryd2.myhost -c 10
celeryd-multi -n celeryd3.myhost -c 10
celeryd-multi -n celeryd4.myhost -c 3
celeryd-multi -n celeryd5.myhost -c 3
リストは名前付きワーカーでも機能します。
$ celeryd-multi start foo bar baz xuzzy -c 3 -c:foo,bar,baz 10
celeryd-multi -n foo.myhost -c 10
celeryd-multi -n bar.myhost -c 10
celeryd-multi -n baz.myhost -c 10
celeryd-multi -n xuzzy.myhost -c 3

ワーカーは、結果バックエンド process_cleanup メソッド after タスクの実行前ではなく呼び出しを行うようになりました。
AMQP結果バックエンドがPikaをサポートするようになりました。

Celery 2.0の変更履歴—Pythonドキュメント

目次