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

提供：Dev Guides
Celery/docs/latest/history/changelog-2.2
移動先:案内、検索

セロリ2.2の変更履歴

2.2.8

発売日
2011-11-25 04:00 pm GMT
リリースバイ
ソレムに聞く

セキュリティ修正

  • [セキュリティ： CELERYSA-0001 ] --uid / --gid引数が celery multi 、の場合、デーモンは実際のIDではなく有効なIDを設定していました] celeryd_detach 、セロリビート、セロリイベントが使用されました。

    これは、特権が適切に削除されなかったこと、および後でスーパーバイザー特権を取り戻すことができることを意味します。


2.2.7

発売日
2011-06-13 04:00 pm BST
リリースバイ
ソレムに聞く

  • 新しいシグナル：：signal： `after_setup_logger` および：signal：` after_setup_task_logger`

    これらの信号は、Celeryがログを設定した後、ログ構成を拡張するために使用できます。

  • Redis結果バックエンドがRedis2.4.4で動作するようになりました。

  • multi：--gidオプションが正しく機能するようになりました。

  • ワーカー：文字列表現の代わりにトレースバックのreprを誤って使用して再試行しました。

  • App.config_from_object：モジュールの属性ではなく、モジュールをロードするようになりました。

  • オブジェクトのロギングで「 」


2.2.6

発売日
2011-04-15 04:00 pm CEST
リリースバイ
ソレムに聞く

重要な注意事項

  • ：pypi： `Kombu` 1.1.2に依存するようになりました。

  • このバージョンはPython3のみをサポートしているため、依存関係リストは、：pypi： `python-dateutil` 2.xが不要であることを明示的に指定するようになりました。

    誤ってdateutil2.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とpropagateを受け入れませんでした

    引数。

  • ワーカー：次の場合にワーカーがシャットダウンしないバグを修正しました

    socket.errorが発生しました。


2.2.5

発売日
2011-03-28 06:00 pm CEST
リリースバイ
ソレムに聞く

重要な注意事項

  • 昆布1.0.7に依存するようになりました


ニュース

  • 現在、ドキュメントはRead The Docs（ http://docs.celeryproject.org ）によってホストされており、すべてのリンクが新しいURLを指すように変更されています。

  • ロギング： logrotate.d などの外部ツールを使用したログローテーションをサポートするようになりました（問題＃321）

    これは、WatchedFileHandlerを使用して実行されます。このファイルは、名前が変更されたり削除されたりすると、ファイルを再度開きます。

  • otherqueuesチュートリアルで、Redis /データベースの結果を構成する方法が文書化されました

    バックエンド。

  • gevent：ETAタスクをサポートするようになりました。

    ただし、geventが機能するには、CELERY_DISABLE_RATE_LIMITS=Trueが必要です。

  • TaskSetユーザーガイド：TaskSetコールバックレシピが含まれるようになりました。

  • イベントレット：新しいシグナル：

    • eventlet_pool_started

    • eventlet_pool_preshutdown

    • eventlet_pool_postshutdown

    • eventlet_pool_apply

    詳細については、celery.signalsを参照してください。

  • 新しい：setting： `BROKER_TRANSPORT_OPTIONS` 設定を使用して、特定のブローカートランスポートに追加の引数を渡すことができます。

  • ワーカー：worker_pidは、ブロードキャストコマンドによって返される要求情報の一部になりました。

  • TaskSet.apply / Taskset.apply_asyncは、オプションのtaskset_id引数を受け入れるようになりました。

  • これで、taskset_id（存在する場合）がタスク要求コンテキストで使用可能になります。

  • SQLAlchemyの結果バックエンド：taskset_id列とtaskset_id列に一意の制約が追加されました（これを有効にするには、テーブルを再作成する必要があります）。

  • タスクユーザーガイド：結果バックエンドの選択に関するセクションを追加しました。

  • 未使用の属性AsyncResult.uuidを削除しました。


修正

  • multiprocessing.Pool：WorkerLostErrorでジョブをマークするときの競合状態を修正しました（問題＃268）。

    プロセスは、終了する前に結果を公開している可能性がありますが、これが事実であることを検出する信頼できる方法はありません。

    したがって、WorkerLostErrorで結果をマークする前に10秒待つ必要があります。 これにより、結果ハンドラーに結果を取得する機会が与えられます。

  • multiprocessing.Pool：レート制限が無効になっていると、シャットダウンがハングする可能性があります。

    MainThreadがプールセマフォが解放されるのを待っていたときに競合状態が発生しました。 未確認のジョブがある場合、ResultHandlerは5秒後に終了しますが、それらを開始するためのワーカープロセスが残っていません（結果キューから消費していないack + resultがまだ存在する可能性があるため、タイムアウトする必要があります。 ワーカープロセスがない状態で5秒後に受信される可能性はほとんどありません）。

  • celerybeat：--detachオプションが設定されていない場合でも、pidfileを作成するようになりました。

  • eventlet / gevent：ブロードキャストコマンドコンシューマーは現在、別のグリーンスレッドで実行されています。

    これにより、アクティブなタスクが多数ある場合でも、ブロードキャストコマンドが優先されます。

  • 内部モジュールcelery.worker.controllersの名前がcelery.worker.mediatorに変更されました。

  • ワーカー：スレッドは、os._exitを呼び出すことによってプログラムを終了するようになりました。これは、構文エラーやその他の回復不能なエラーが発生した場合に確実に終了する唯一の方法であるためです。

  • maybe_timedeltaのタイプミスを修正しました（問題＃352）。

  • ワーカー：ブロードキャストコマンドは、警告ではなくログレベルのデバッグでログに記録されるようになりました。

  • AMQP結果バックエンド：接続が失われた場合にキャッシュされたチャネルをリセットするようになりました。

  • AMQP結果バックエンドを使用したポーリング結果が正しく機能していませんでした。

  • レート制限：タスクがない場合はスリープしなくなり、タスクの受信状態を待機します（パフォーマンスの向上）。

  • ConfigurationView：iter(dict)は、アイテムではなくキーを返す必要があります（問題＃362）。

  • celerybeat：PersistentSchedulerは、破損したスケジュールファイルを自動的に削除するようになりました（問題＃346）。

  • 位置コマンドライン引数をサポートしないプログラムは、ユーザーフレンドリーなエラーメッセージを提供するようになりました。

  • --versionを表示しているときに、プログラムが構成ファイルを読み込もうとしなくなりました（問題＃347）。

  • オートスケーラー：「すべてのプロセスがビジーです」というログメッセージが、エラーではなく重大度のデバッグになりました。

  • ワーカー：メッセージ本文をデコードできない場合、ログに記録するときにsafe_strを通過するようになりました。

    これは、失敗をログに記録しようとしたときに追加のデコードエラーが発生しないようにするためです。

  • app.config_from_object / app.config_from_envvarがすべてのローダーで機能するようになりました。

  • 結果のバックエンド名が不明な場合に、ユーザーフレンドリーなエラーメッセージを出力するようになりました（問題＃349）。

  • celery.contrib.batches：タスクリクエストにログレベルとログファイルを設定するようになり、task.get_loggerがバッチタスクで機能するようになりました（問題＃357）。

  • ワーカー：amqpトランスポートを使用していて、プリフェッチカウント値が65535を超えた場合、例外が発生しました（問題＃359）。

    プリフェッチカウントは、ETA /カウントダウンが定義されている受信タスクごとに増分されます。 プリフェッチカウントが短いため、最大値65535しかサポートできません。 値が最大値を超えた場合、プリフェッチカウントを無効にし、値が再び制限を下回るとすぐに再度有効になります。

  • cursesmon：バインドされていないローカルエラーを修正しました（問題＃303）。

  • eventlet / geventがオンデマンドでインポートされるようになったため、autodocはeventlet / geventをインストールしなくてもモジュールをインポートできます。

  • ワーカー：AckコールバックがAttributeErrorを適切に処理するようになりました。

  • Task.after_returnは、結果が書き込まれた後、常にと呼ばれるようになりました。

  • Cassandra Result Backend：最新のpycassaバージョンで動作するはずです。

  • multiprocessing.Pool：putlockセマフォが何度もリリースされても気になりません（これは、1つ以上のワーカープロセスが強制終了された場合に発生する可能性があります）。

  • SQLAlchemy結果バックエンド：誤って削除されたdate_doneが再び返されるようになりました（問題＃325）。

  • Task.requestコンテキストは常に初期化されるようになり、リクエストコンテキストをアクティブに使用している場合でも、タスク関数の呼び出しが直接機能するようになりました。

  • TaskSet.applyの結果を反復処理するときに発生する例外が修正されました。

  • eventlet：過去にETAを使用してタスクを適切にスケジュールするようになりました。


2.2.4

発売日
2011-02-19 00:00 AM CET
リリースバイ
ソレムに聞く

修正

  • ワーカー：2.2.3でエラーログが壊れ、トレースバックがログに記録されませんでした。
  • AMQP結果バックエンド：キューに複数の結果メッセージがある場合、ポーリングタスクの状態が正しく機能しませんでした。
  • TaskSet.apply_async()およびTaskSet.apply()は、オプションのtaskset_idキーワード引数をサポートするようになりました（問題＃331）。
  • 現在のタスクセットID（存在する場合）は、タスクコンテキストでrequest.tasksetとして使用できるようになりました（問題＃329）。
  • SQLAlchemy結果バックエンド： date_done は誤って削除されたため、結果の一部ではなくなりました。 再び利用可能になりました（問題＃325）。
  • SQLAlchemy結果バックエンド： Task.id および TaskSet.taskset_id に一意の制約を追加しました。 これを有効にするには、テーブルを再作成する必要があります。
  • TaskSet.apply()の結果を反復処理するときに発生する例外を修正しました。
  • タスクユーザーガイド：結果バックエンドの選択に関するセクションを追加しました。


2.2.3

発売日
2011-02-12 04:00 pm CET
リリースバイ
ソレムに聞く

修正

  • ：pypi： `Kombu` 1.0.3に依存するようになりました

  • Task.retryは、デフォルト値を変更するために使用されるmax_retries引数をサポートするようになりました。

  • multiprocessing.cpu_count は、これがサポートされていないプラットフォームでNotImplementedErrorを発生させる可能性があります（問題＃320）。

  • ログに記録されたオブジェクトが文字列でない場合、ログメッセージの色付けが壊れました。

  • init-scriptドキュメントのいくつかのタイプミスを修正しました。

  • リグレッションにより、 Task.exchange および Task.routing_key は無効になりました。 これは修正されました。

  • ルーティングユーザーガイド：タイプミスを修正しました。：setting： `CELERY_ROUTES` のルーターはクラスではなくインスタンスである必要があります。

  • celeryev は、--pidfile引数が設定されていても、pidfileを作成しませんでした。

  • タスクロガー形式は使用されなくなりました（問題＃317）。

    タスクのIDと名前がログメッセージの一部になりました。

  • repr()の安全なバージョンが戦略的な場所で使用され、__repr__が壊れているオブジェクトがワーカーをクラッシュさせたり、エラーを理解しにくくしたりしないようにします（問題＃298）。

  • リモートコントロールコマンド：control： `active_queues` ：実行時に追加されたキューを考慮していませんでした。

    さらに、このコマンドによって応答される辞書の構造が異なります。交換キーは、交換宣言を完全に含む辞書になりました。

  • celery worker -Qオプションは未使用のキュー宣言を削除したため、タスクのルーティングが失敗する可能性がありました。

    キューは削除されなくなりましたが、 app.amqp.queues.consume_from（）が消費するキューのリストとして使用されます。

    これにより、すべてのキューがルーティング目的で使用できるようになります。

  • celeryctl： inspect active_queues コマンドをサポートするようになりました。


2.2.2

発売日
2011-02-03 04:00 pm CET
リリースバイ
ソレムに聞く

修正

  • celerybeatはスケジュールを正しく読み取ることができなかったため、：setting： `CELERYBEAT_SCHEDULE` のエントリはスケジュールされませんでした。

  • タスクエラーログメッセージに exc_info が再び含まれるようになりました。

  • eta 引数を task.retry で使用できるようになりました。

    以前は、カウントダウン引数によって上書きされていました。

  • celery multi / celeryd_detach： celeryworker コマンドの実行時に発生したエラーをログに記録するようになりました。

  • デーモン化チュートリアル：タイプミスを修正--time-limit 300-> --time-limit=300

  • ロギングの色は、ログメッセージの文字列以外のオブジェクトを壊しました。

  • setup_task_loggerは、魔法のタスクのクワーグについての仮定をしなくなりました。


2.2.1

発売日
2011-02-02 04:00 pm CET
リリースバイ
ソレムに聞く

修正

  • イベントレットプールでメモリリークが発生していました（問題＃308）。
  • 非推奨の機能celery.execute.delay_taskが誤って削除され、再び利用できるようになりました。
  • BasePool.on_terminateスタブは存在しませんでした
  • celeryd_detach：ユーザー/グループ名が存在しない場合に読み取り可能なエラーメッセージを追加します。
  • エラーをログに記録するときのUnicodeデコードエラーのよりスマートな処理。


2.2.0

発売日
2011-02-01 10:00 AM CET
リリースバイ
ソレムに聞く

重要な注意事項

  • にんじんは：pypi： `昆布` に置き換えられました

    KombuはPython用の次世代メッセージングライブラリであり、下位互換性を損なうことなく修正するのが困難であったCarrotに存在するいくつかの欠陥を修正します。

    また、次のように追加します。

    • 仮想トランスポートのファーストクラスのサポート。 Redis、Django ORM、SQLAlchemy、Beanstalk、MongoDB、CouchDB、およびインメモリ。

    • イントロスペクションによる一貫したエラー処理、

    • 接続エラーとチャネルエラーを適切に処理することにより、操作が確実に実行されるようにする機能。

    • メッセージ圧縮（zlib、bz2、またはカスタム圧縮スキーム）。

    これは、 ghettoq が提供する機能がデフォルトですでにセロリで利用可能であるため、不要になったことを意味します。 仮想トランスポートは、交換（直接およびトピック）のサポートを備えたより多くの機能も備えています。 Redisトランスポートはファンアウト交換もサポートしているため、ワーカーのリモートコントロールコマンドを実行できます。

  • 廃止が保留されているマジックキーワード引数。

    魔法のキーワード引数は、多くの問題と癖の原因でした。特に、タスクとデコレータの問題、および知らない人のためのキーワード引数での名前の衝突です。

    魔法のキーワード引数を非推奨にする方法を見つけるのは簡単ではありませんでしたが、これは理にかなっている解決策であり、既存のコードに悪影響を与えることはないと考えています。

    魔法のキーワード引数のない世界への道は次のとおりです。

    • 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

    新着

    self.request.args

    新着

    self.request.kwargs

    さらに、次のメソッドは現在のコンテキストを自動的に使用するようになったため、 kwargs を手動で渡す必要がなくなりました。

    • task.retry

    • task.get_logger

    • task.update_state


  • イベントレットのサポート。

    これは、I / Oバウンドタスクにとって素晴らしいニュースです。

    プールの実装を変更するには、celery worker --pool引数を使用するか、：setting： `CELERYD_POOL` 設定をグローバルに使用します。 これは、クラスのフルネーム、または次のエイリアスのいずれかになります： processes 、 eventlet 、 gevent 。

    詳細については、ユーザーガイドのイベントレットとの同時実行セクションを参照してください。

    なぜgeventしないのですか？

    最初の代替同時実行実装では、 Eventlet に焦点を当てましたが、実験的な gevent プールも利用できます。 これには、いくつかの機能、特にETAタスクをスケジュールする機能がありません。

    gevent のサポートがバージョン2.3までに完全な機能になることを願っていますが、これはユーザーの要求（および貢献）によって異なります。

  • Python 2.4のサポートは廃止されました！

    これがPython2.4をサポートする最後のバージョンであることを発表できてうれしいです^ H ^ H ^ H ^ H ^ Hsad。

    現在Python2.4を使用している場合は、多少の騒ぎを起こすことをお勧めします。 パッケージのメンテナ、システム管理者、上司に文句を言ってください。次に進む時間だと伝えてください。

    withステートメント、コルーチン、条件式、拡張されたtryブロックを利用したいことは別として、コードベースには2.4に関連するハックと回避策が多数含まれているため、単なる妥協ではなく、犠牲。

    それが本当にあなたの選択ではなく、Pythonの新しいバージョンにアップグレードするオプションがない場合は、Celery2.2を引き続き使用できます。 重要な修正は、関心がある限り、バックポートすることができます。

  • ワーカー：子ワーカープロセスの自動スケーリングをサポートするようになりました。

    --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

  • ワーカーは構成なしで起動するようになり、構成はコマンドラインで直接指定できます。

    構成オプションは、最後の引数の後に2つのダッシュで区切って表示する必要があります。

    $ 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（）を使用してください。


  • celery.task.base からの TaskSet のインポートは非推奨になりました。

    次を使用する必要があります。

    >>> from celery.task import TaskSet

    代わりは。

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

    • active_queues

      ワーカーが現在消費しているキュー宣言を返します。


  • 接続が失われたり失敗したりした場合に、タスクメッセージの公開を再試行する機能が追加されました。

    これはデフォルトでは無効になっていますが、：setting： `CELERY_TASK_PUBLISH_RETRY` 設定を使用して有効にし、：setting：` CELERY_TASK_PUBLISH_RETRY_POLICY` 設定で調整できます。

    さらに、 retry および retry_policy キーワード引数が Task.apply_async に追加されました。

    ノート

    apply_async に対して retry 引数を使用するには、パブリッシャー/接続を手動で処理する必要があります。

  • 定期的なタスククラス（ @periodic_task / PeriodicTask ）は、ソースコードで以前に示されたように非推奨になりません。

    ただし、より柔軟な：setting： `CELERYBEAT_SCHEDULE` 設定を使用することをお勧めします。

  • celery multi を使用したワーカーの組み込みのデーモン化サポートは実験的ではなくなり、本番品質と見なされます。

    新しい汎用initスクリプトを使用する場合は、汎用initスクリプトを参照してください。

  • ：setting： `CELERY_MESSAGE_COMPRESSION` 設定、または apply_async の compression 引数を使用したメッセージ圧縮のサポートが追加されました。 これは、ルーターを使用して設定することもできます。

  • ワーカー：受信時にすべてのスレッドのスタックトレースをログに記録するようになりました

    SIGUSR1 シグナル（CPython 2.4、Windows、またはJythonでは機能しません）。

  • 現在タスクを処理しているワーカープロセスをリモートで終了/強制終了できるようになりました。

    revoke リモートコントロールコマンドが terminate 引数をサポートするようになりました。デフォルトの信号は TERM ですが、 signal 引数を使用して指定できます。 Signalは、Python標準ライブラリのsignalモジュールで定義されている任意の信号の大文字の名前にすることができます。

    タスクを終了すると、タスクも取り消されます。

    例：

    >>> 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（）。

    利用可能な場合、このバージョンは、結果を1つずつフェッチする join（）とは異なり、バックエンド機能を使用して一度に複数の結果を取得します。

    これまでのところ、AMQP結果バックエンドでのみサポートされています。 MemcachedとRedisのサポートは後で追加される可能性があります。

  • TaskSetResult.join および AsyncResult.wait の実装が改善されました。

    interval キーワード引数が両方に追加されたため、ポーリング間隔を指定できます（デフォルトの間隔は0.5秒です）。

    propagate キーワード引数が result.wait（）に追加されました。これがFalseに設定されている場合、エラーが発生する代わりに返されます。

    警告

    データベース結果バックエンドを使用する場合は、ポーリング間隔を短くする必要があります。ポーリングを頻繁に行うと、データベースの負荷が高くなる可能性があるためです。

  • タスクを受け入れるチャイルドワーカープロセスのPIDが、：event： `task-started` イベントのフィールドとして送信されるようになりました。

  • 次のフィールドがワーカークラスのすべてのイベントに追加されました。

    • sw_ident ：ワーカーソフトウェアの名前（例："py-celery"）。

    • sw_ver ：ソフトウェアバージョン（例：2.2.0）。

    • sw_sys ：オペレーティングシステム（Linux、Windows、Darwinなど）。


  • 精度を高めるために、タスク期間の計算には、マルチプロセッシングワーカープロセスによって報告された開始時間が使用されます。

    以前は、acceptコールバックによって報告された時間が使用されていました。

  • celerybeat ： –detach を使用した新しい組み込みデーモン化サポート

    オプション。

  • celeryev ： –detach を使用した新しい組み込みデーモン化サポート

    オプション。

  • TaskSet.apply_async ： Publisher 引数を使用して、カスタムパブリッシャーをサポートするようになりました。

  • ：setting： `CELERY_SEND_TASK_SENT_EVENT` 設定を追加しました。

    有効にすると、すべてのタスクでイベントが送信されるため、モニターは、ワーカーがタスクを受信する前にタスクを追跡できます。

  • celerybeat ：呼び出し時にブローカー接続を再利用するようになりました

    スケジュールされたタスク。

  • 使用する構成モジュールとローダーをコマンドラインで指定できるようになりました。

    例えば：

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

  • 追加されたシグナル： beat_init および beat_embedded_init


  • Redis結果バックエンド：非推奨の設定 REDIS_TIMEOUT および REDIS_CONNECT_RETRY を削除しました。

  • セロリワーカー用のCentOSinit-scriptが extra / centos で利用可能になりました。

  • 現在、：pypi： `pyparsing` バージョン1.5.0以降に依存しています。

    ：pypi： `pyparsing` 1.4.xでCeleryを使用すると問題が報告されているため、最新バージョンにアップグレードしてください。

  • 多くの新しい単体テストが作成され、現在は合計95％をカバーしています。


修正

  • celeryev Curses Monitor：サイズ変更処理とUIレイアウトの改善（問題＃274 +問題＃276）

  • AMQPバックエンド：タスク結果の送信中に発生した例外が、無音ではなく伝播されるようになりました。

    その後、ワーカーはこれらのエラーの完全なトレースバックをログに表示します。

  • AMQPバックエンド：ポーリングが成功した後に結果キューを削除しなくなりました。これは、代わりに：setting： `CELERY_AMQP_TASK_RESULT_EXPIRES` 設定で処理する必要があるためです。

  • AMQPバックエンド：結果をポーリングする前にキューが宣言されるようになりました。

  • Windows：ワーカー： -B オプションを指定して実行するとエラーが表示されます。

    celerybeat埋め込みを実行すると、Windowsで機能しないことがわかっているため、代わりにcelerybeatを別のサービスとして実行することをお勧めします。

  • Windows：ユーティリティはWindowsでANSIカラーコードを出力しなくなりました

  • camqadm：紛らわしいトレースバックを表示する代わりに終了するだけで Control-c を適切に処理するようになりました。

  • Windows：すべてのテストがWindowsで合格しています。

  • setup.pyからbin /ディレクトリと scripts セクションを削除します。

    これは、setuptoolsエントリポイントに完全に依存していることを意味します。


実験的

  • Jython：ワーカーはスレッドプールを使用してJythonで実行されるようになりました。

    すべてのテストに合格しますが、まだ角を曲がったところにバグが潜んでいる可能性があります。

  • PyPy：ワーカーがPyPyで実行されるようになりました。

    プールなしで実行されるため、並列実行を取得するには、複数のインスタンスを開始する必要があります（たとえば、 multi を使用）。

    残念ながら、最初のベンチマークでは、pypy-1.4.1 + JITでパフォーマンスが30％低下することが示されているようです。 これがなぜであるかを知りたいので、ご期待ください。

  • PublisherPool： apply_async への retry 引数で使用されるタスクパブリッシャーと接続の実験的なプール。

    以下のサンプルコードは、接続とチャネルを再利用し、接続が失われた場合はタスクメッセージの送信を再試行します。

    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)



「https://www.finddevguides.com/index.php?title=Celery/docs/latest/history/changelog-2.2&oldid=94332」から取得
Powered by MediaWiki