Celery 2.1の変更履歴—Pythonドキュメント
セロリ2.1の変更履歴
2.1.4
- 発売日
- 2010-12-03 12:00 pm CEST
- リリースバイ
- ソレムに聞く
修正
- apply_async の実行オプションが、アクティブなルーターから返されるオプションよりも優先されるようになりました。 これは最近導入されたリグレッションでした（問題＃244）。
- cursesモニター：長い引数が切り捨てられるようになったため、cursesが範囲外のエラーでクラッシュしません（問題＃235）。
- multi：制御コマンドの処理中に発生したチャネルエラーは、ワーカーをクラッシュさせなくなりましたが、代わりに重大度エラーでログに記録されます。
- SQLAlchemyデータベースバックエンド：クライアントが保留状態を書き込んだときに発生する競合状態を修正しました。 Djangoデータベースバックエンドと同様に、保留状態は保存されなくなりました（問題＃261 +問題＃262）。
- エラーメール本文は、 str（exception）の代わりに repr（exception）を使用するようになりました。後者は、Unicodeデコードエラーを引き起こす可能性があるためです（問題＃245）。
- エラーメールのタイムアウト値は、：setting： `EMAIL_TIMEOUT` 設定を使用して構成できるようになりました。
- celeryev ：Windowsで動作するようになりました（ただし、cursesモニターはcursesがないと動作しません）。
- ユニットテストの出力で非標準文字が出力されなくなりました。
- ワーカー：接続がリセットされると、ブロードキャストコンシューマーが閉じられるようになりました。
- ワーカー：メッセージの確認中に発生したエラーを適切に処理するようになりました。
- *; TaskRequest.on_failure は、現在のファイルシステムを使用してトレースバックをエンコードするようになりました
- エンコーディング（問題＃286）。
- EagerResult をピクルスできるようになりました（問題＃288）。
2.1.3
- 発売日
- 2010-11-09 05:00 pm CEST
- リリースバイ
- ソレムに聞く
timer2 のデッドロックが修正され、 djcelerymon / celeryev -c がハングする可能性がありました。
EventReceiver ：ワーカーを見つけるためにハートビートリクエストを送信するようになりました。
これは、 celeryev とその友人が、起動時にすぐにワーカーを見つけることを意味します。
celeryevcursesモニター：screen_delayを10msに設定して、画面がより頻繁に更新されるようにします。古いPythonバージョンで
AsyncResultをピクルスするときのピクルスエラーを修正しました。ワーカー：アクティブなプリフェッチ制限がない場合でも、プリフェッチカウントはETAタスクによってデクリメントされました。
2.1.2
- リリースデータ
- TBA
修正
- ワーカー：再試行されたタスクに対して：event： `task-retried` イベントを送信するようになりました。
- ワーカー：
@WorkerLostErrorの無視結果とタイムアウトエラーを尊重するようになりました。 celerybeat：ロギング設定信号を使用する場合のcelerybeatロギングのUnboundLocalErrorを修正しました。- ワーカー：すべてのログメッセージに exc_info が含まれるようになりました。
2.1.1
- 発売日
- 2010-10-14 02:00 pm CEST
- リリースバイ
- ソレムに聞く
修正
今再びWindowsで作業しています。
pwd/grpモジュールへの依存関係を削除しました。スナップショット：イベントの損失につながる競合状態を修正しました。
ワーカー：タイムスタンプに変換できないETAを持つタスクを拒否します。
問題＃209を参照してください
concurrency.processes.pool：セマフォはタスクごとに2回リリースされました（ACKと結果の準備の両方で）。
これは修正され、タスクごとに1回だけリリースされるようになりました。
docs / configuration：タイプミス CELERYD_TASK_SOFT_TIME_LIMIT -> ：setting： `CELERYD_TASK_SOFT_TIME_LIMIT` を修正しました。
問題＃214を参照してください
制御コマンド dump_scheduled ：古い.info属性を使用していました
- multi：反復中に変更されたサイズを設定するバグを修正しました
restartコマンドで発生します。
ワーカー：誤って追加のコマンドライン引数を使用しようとしました。
これにより、次のようなエラーが発生します。
キーワード引数 '同時実行' に複数の値を取得しました。
追加のコマンドライン引数は無視されるようになり、このエラーは発生しません。 ただし、将来的には位置引数を使用する権利を留保しますので、この動作に依存しないでください。
celerybeat：ルーターとタスク実行オプションを再び尊重するようになりました。celerybeat：接続の代わりにパブリッシャーを再利用するようになりました。キャッシュ結果バックエンド： cache.set へのexpires引数として
floatを使用することは、Memcachedライブラリによって非推奨になっているため、intに自動的にキャストするようになりました。単体テスト：テスト出力でログと警告を出力しなくなりました。
ニュース
現在、ニンジンバージョン0.10.7に依存しています。
：setting： `CELERY_REDIRECT_STDOUTS` 、および：setting：` CELERYD_REDIRECT_STDOUTS_LEVEL` の設定を追加しました。
：setting： `CELERY_REDIRECT_STDOUTS` は、ワーカーとビートによって使用されます。 stdout および stderr へのすべての出力は、有効になっている場合、現在のロガーにリダイレクトされます。
：setting： `CELERY_REDIRECT_STDOUTS_LEVEL` は、使用されるログレベルを決定し、デフォルトでは
WARNINGです。：setting： `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を使用して、バインディングキー「key」を使用してタイプ「direct」のキュー「queue」から交換「exchange」で消費を開始する例：$ celeryctl inspect add_consumer queue exchange direct key $ celeryctl inspect cancel_consumer queueceleryctl プログラムの詳細については、管理コマンドラインユーティリティ（検査/制御）を参照してください。
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')- add_consumer(queue, exchange, exchange_type, routing_key,
celerybeat：メッセージを送信できない場合にトレースバックをログに記録するようになりました。celerybeat：デフォルトのソケットタイムアウト30秒を有効にするようになりました。README/ Introduction / homepage： Flask-Celery へのリンクを追加しました。
2.1.0
- 発売日
- 2010-10-08 12:00 pm CEST
- リリースバイ
- ソレムに聞く
重要な注意事項
Celeryは現在、 semver で定義されているバージョン管理セマンティクスに従っています。
これは、奇数/偶数のバージョン管理セマンティクスの使用が許可されなくなったことを意味します。以前のバージョン管理スキームでは、この安定したリリースはバージョン2.2である必要がありました。
現在、Carrot0.10.7に依存しています。
SQLAlchemyに依存しなくなりました。データベース結果バックエンドを使用する場合は、これを個別にインストールする必要があります。
：pypi： `django-celery` には、Django管理インターフェース用のモニターが付属しています。 これは、Djangoユーザーでない場合にも使用できます。 （更新：Django-AdminモニターはFlowerに置き換えられました。モニタリングガイドを参照してください）。
アップグレード後に次のようなエラーが発生した場合： AttributeError： 'module'オブジェクトに属性 'system' がありません、
これは、 celery.platform モジュールの名前が celery.platforms に変更され、組み込みの
platformモジュールと衝突しないためです。以前のCeleryインストールから古い
platform.py（およびおそらくplatform.pyc）ファイルを削除する必要があります。これを行うには、 python を使用して、このモジュールの場所を見つけます。
$ python >>> import celery.platform >>> celery.platform <module 'celery.platform' from '/opt/devel/celery/celery/platform.pyc'>ここで、コンパイルされたモジュールは
/opt/devel/celery/celery/にあり、問題のあるファイルを削除するには、次のようにします。$ rm -f /opt/devel/celery/celery/platform.py*
ニュース
AMQP結果の有効期限のサポートが追加されました（RabbitMQ 2.1.0が必要）
新しい構成オプション：setting： `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：イベントスナップショット有効にすると、ワーカーはワーカーの実行内容に関するメッセージを送信します。 これらのメッセージは「イベント」と呼ばれます。 イベントは、クラスターが何をしているかを示すためにリアルタイムモニターによって使用されますが、長期間にわたるモニターにはあまり役立ちません。 スナップショットを使用すると、クラスターの状態の「写真」を定期的に撮ることができます。 次に、これをデータベースに保存して、統計を生成したり、長期間にわたって監視したりすることができます。
：pypi： `django-celery` には、Django管理インターフェース用のCeleryモニターが付属しています。 これを使用するには、：pypi： `django-celery` スナップショットカメラを実行する必要があります。このカメラは、構成可能な間隔でスナップショットをデータベースに保存します。
Django管理モニターを使用するには、次のことを行う必要があります。
新しいデータベーステーブルを作成します。
$ python manage.py syncdb：pypi： `django-celery` スナップショットカメラを起動します。
$ python manage.py celerycamdjango管理者を開いて、クラスターを監視します。
管理インターフェースには、タスクとワーカーノードが表示され、タスクの取り消しやレート制限、ワーカーノードのシャットダウンなどのアクションを実行することもできます。
events用のDebianinit.dスクリプトも利用できます。詳細については、デーモン化を参照してください。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：ワーカーノードの管理と検査、タスクの適用、タスクの結果の検査を行うための新しいコマンドラインユーティリティ。も参照してください
いくつかの例：
$ 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/--logfile引数を使用して構成され、これはすべての定義済みロガーに使用されます。ワーカーはstdoutとstderrもCeleryロガーにリダイレクトすることを忘れないでください。手動でロギングを構成する場合は、標準のoutも手動でリダイレクトする必要があります。
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)ワーカー追加されたコマンドラインオプション
--include：インポートする（タスク）モジュールのコンマ区切りのリスト。
例：
$ celeryd -I app1.tasks,app2.tasksワーカー：rootユーザーとして実行している場合に警告を発するようになりました（euidは0）。
celery.messaging.establish_connection()：キーワード引数「defaults」を使用して使用されるデフォルトをオーバーライドする機能。ワーカー： multiprocessing.freeze_support（）を使用するようになり、 py2exe 、 PyInstaller 、 cx_Freeze などで動作するようになりました。
ワーカー：：state： `STARTED` 状態のメタデータがさらに含まれるようになりました：タスクを開始したワーカーのPIDとホスト名。
問題＃181を参照してください
サブタスク： subtask（）への追加のキーワード引数をタスクキーワード引数にマージします。
例えば：
>>> s = subtask((1, 2), {'foo': 'bar'}, baz=1) >>> s.args (1, 2) >>> s.kwargs {'foo': 'bar', 'baz': 1}問題＃182を参照してください。
ワーカー：同じ仮想ホストで同じ名前のワーカーノードが実行されている場合に警告を発するようになりました。
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 （ Optimization ）を実装しています。
- ワーカー：：state： `FAILURE` の結果を保存する
@WorkerLostError例外が発生します（ワーカープロセスが消えました）。
ワーカー： * TimeLimitExceeded 例外のいずれかが発生した場合、：state： `FAILURE` の結果を保存します。
結果のクリーンアップを担当する定期的なタスクをリファクタリングしました。
- バックエンドのクリーンアップタスクは、次の場合にのみスケジュールに追加されるようになりました。
スケジュールに「celery.backend_cleanup」という名前の定期的なタスクがすでに含まれている場合、スケジュールは変更されないため、バックエンドのクリーンアップタスクの動作を簡単に変更できます。
タスクは、最初に実行されてから毎日ではなく、毎日午前4時に実行されるようになりました（ run_every の代わりにCrontabスケジュールを使用）
- celery.task.builtins.DeleteExpiredTaskMetaTask に名前が変更されました
->
celery.task.builtins.backend_cleanup
タスク自体の名前が「celery.delete_expired_task_meta」から「celery.backend_cleanup」に変更されました。
問題＃134を参照してください。
SQLAlchemy / Memcached / Redis / Tokyo Tyrantバックエンドに AsyncResult.forget を実装しました（タスク結果を忘れて削除します）。
問題＃184を参照してください。
TaskSetResult.join：「propagate = True」引数を追加しました。Falseに設定すると、サブタスクで発生する例外は再発生しません。task.backend.store_result（task_id、meta、state）へのショートカットとして Task.update_state（task_id、state、meta）を追加しました。
バックエンドインターフェイスは「プライベート」であり、用語が古くなっているため、これを
Taskに移動して使用できるようにすることをお勧めします。timer2：
stop()で self.running = False を設定して、 stop（）への後続の呼び出しで再び参加しようとしないようにします。ログの色は、Windowsではデフォルトで無効になっています。
celery.platform の名前が
celery.platformsに変更されたため、組み込みのplatformモジュールと衝突しません。Mediator + Poolコールバックで発生する例外は、ワーカーを停止する代わりにキャッチされ、ログに記録されるようになりました。
Redis結果バックエンド：Redis EXPIRE コマンドを使用した結果の有効期限をサポートするようになりました。
単体テスト：スレッドを分解時に実行したままにしないでください。
ワーカー：ログに表示されるタスクの結果が46文字に切り捨てられるようになりました。
- Task .__ name __ は self .__ class __.__ name __ のエイリアスになりました。
このようにして、タスクは通常の関数のように内省します。
Task.retry ：kwargs引数が空の場合、
TypeErrorを発生させるようになりました。問題＃164を参照してください。
timedelta_seconds：Python 2.7で実行している場合は、timedelta.total_secondsを使用しますTokenBucket：汎用トークンバケットアルゴリズムcelery.events.state：バッファリングのサポートを含め、クラスター状態の記録を一時停止および再開できるようになりました。- State.freeze(buffer=True)
ストリームの記録を一時停止します。
buffer がtrueの場合、フリーズ中に受信したイベントはバッファリングされ、後で再生される可能性があります。
- State.thaw(replay=True)
ストリームの記録を再開します。
replay がtrueの場合、記録されたバッファが適用されます。
- State.freeze_while(fun)
適用する関数を使用すると、前にストリームをフリーズし、関数が戻った後にバッファーを再生します。
EventReceiver.captureタイムアウトキーワード引数をサポートするようになりました。ワーカー：：setting： `CELERY_RATE_LIMITS` が有効になっている場合、メディエータースレッドが無効になり、タスクは準備完了キューを経由せずにプールに直接送信されます（最適化）。
修正
プール： TimeoutHandler によってタイムアウトしたプロセスは、スーパーバイザーが参加する必要があるため、内部プロセスリストから削除しないでください。
問題＃192を参照してください。
TaskPublisher.delay_task は交換引数をサポートするようになったため、同じパブリッシャーを使用してタスクを一括送信するときに交換をオーバーライドできます
問題＃187を参照してください。
：setting： `CELERY_IGNORE_RESULT` が有効になっている場合、ワーカーはタスクを取り消されたものとしてマークしなくなりました。
問題＃207を参照してください。
AMQP結果バックエンド：：setting： `CELERY_TRACK_STARTED` が有効になっている場合、 result.get（）のバグを修正しました。
result.get（）は、：state： `STARTED` 状態を受け取った後に消費を停止します。
プールスーパーバイザーによって作成された新しいプロセスがタスクキューからの読み取り中にスタックするバグを修正しました。
リモートコントロールコマンドの応答キューを宣言するときのタイミングの問題を修正しました
この問題により、返信が失われる可能性がありましたが、現在は修正されています。
下位互換性のある LoggerAdapter の実装：Python2.4で機能するようになりました。
また、いくつかの新しいメソッドのサポートが追加されました： fatal 、 makeRecord 、 _log 、 log 、 isEnabledFor 、[X133X ] addHandler 、 removeHandler 。
実験的
multi：デーモン化のサポートが追加されました。
multiを使用して、ワーカーノードを開始、停止、および再起動できるようになりました。
$ celeryd-multi start jerry elaine george kramerこれにより、PIDファイルとログファイル（
[email protected]、…、[email protected]）も作成されます。 これらのファイルの場所を指定するには、 –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再起動します。 古いノードがシャットダウンされると、ノードは1つずつ再起動されます。
$ celeryd-multi restart jerry elaine george kramerノードの強制終了（警告：現在実行中のタスクを破棄します）：
$ celeryd-multi kill jerry elaine george kramerヘルプについては、 celeryd-multiヘルプを参照してください。
multi： start コマンドの名前が show に変更されました。
celeryd-multi start は、実際にワーカーノードを起動およびデタッチするようになりました。 コマンドを生成するには、 celeryd-multi show を使用する必要があります。
ワーカー： –pidfile 引数を追加しました。
ワーカーは、起動時にpidを書き込みます。 このファイルが存在し、含まれているpidがまだ生きている場合、ワーカーは開始されません。
celeryd-multi を使用した一般的なinit.dスクリプトを追加しました
ドキュメンテーション
ユーザーガイドセクションを追加：モニタリング
ユーザーガイドセクションを追加：定期的なタスク
getting-started / periodic-tasks から移動し、更新しました。
チュートリアル/外部は新しいセクション「コミュニティ」に移動しました。
ドキュメントのすべてのセクションに参照が追加されました。
これにより、ドキュメント間のリンクが簡単になります。
