1

したがって、Celery 3.0.19 での私のタスクの一部では、Celery は明らかにキュー属性を尊重しておらず、代わりにデフォルトのセロリ キューにタスクを送信しています。

/This is a stupid test with the proprietary code ripped out.  
def run_chef_task(task, **env):
if env is None:
    env = {}
if not task_name is None:
    env['CHEF'] = task_name

print env
cmd = []
if len(env):
    cmd = ['env']
    for key, value in env.items():
        if not isinstance(key, str) or not isinstance(value, str):
            raise TypeError(
                "Environment Values must be strings ({0}, {1})"\
                .format(key, value))
        key = "ND" + key.upper()
        cmd.append('%s=%s' % (key, value))


cmd.extend(['/root/chef/run_chef', 'noudata_default'])
print cmd
ret = " ".join(cmd)
ret = subprocess.check_call(cmd)
print 'CHECK'
return ret,cmd

r = run_chef_task.apply_async(args=['mongo_backup], queue = 'my_special_queue_with_only_one_worker') r.get() # すぐに戻ります

花に行く。タスクを検索します。タスクが実行されたワーカーを検索します。ワーカーが異なること、およびタスクが実行されたワーカーが特別なワーカーではないことを確認してください。Flower が「special_worker」は「my_special_queue」のみにあり、「special_worker」のみが「my_special_queue」にはないと言っていることを確認します。

ここに本当に興味深い部分があります：

ブローカーで rabbitmq-management をプルアップします (ブローカーがブローカーであることを確認します)。
ブローカーを介して正しいキューの正しいワーカー (検証済み) にメッセージが送信されました。その直後、別のメッセージがセロリ キューに送信されました

ワーカーのログファイルには、タスクを受け入れて完了したことが示されています。

[2013-05-16 02:24:15,455: INFO/MainProcess] Got task from broker: noto.tasks.chef_tasks.run_chef_task[0dba1107-2bb5-4c19-8df3-8a74d8e1234c]
[2013-05-16 02:24:15,456: DEBUG/MainProcess] TaskPool: Apply <function _fast_trace_task at 0x2479c08> (args:('noto.tasks.chef_tasks.run_chef_task', '0dba1107-2bb5-4c19-8df3-8a74d8e1234c', ['mongo_backup'], {}, {'utc': True, 'is_eager': False, 'chord': None, 'group': None, 'args': ['mongo_backup'], 'retries': 0, 'delivery_info': {'priority': None, 'routing_key': u'', 'exchange': u'celery'}, 'expires': None, 'task': 'noto.tasks.chef_tasks.run_chef_task', 'callbacks': None, 'errbacks': None, 'hostname': 'manager1.i-6e958f0f', 'taskset': None, 'kwargs': {}, 'eta': None, 'id': '0dba1107-2bb5-4c19-8df3-8a74d8e1234c'}) kwargs:{})
// This is output from the task
[2013-05-16 02:24:15,459: WARNING/PoolWorker-1] {'CHEF': 'mongo_backup'}

[2013-05-16 02:24:15,463: WARNING/PoolWorker-1] ['env', 'NDCHEF=mongo_backup', '/root/chef/run_chef', 'default']
[2013-05-16 02:24:15,477: DEBUG/MainProcess] Task accepted: noto.tasks.chef_tasks.run_chef_task[0dba1107-2bb5-4c19-8df3-8a74d8e1234c] pid:17210
...A bunch of boring debug logs repeating the registered tasks
[2013-05-16 02:31:45,061: INFO/MainProcess] Task noto.tasks.chef_tasks.run_chef_task[0dba1107-2bb5-4c19-8df3-8a74d8e1234c] succeeded in 88.438395977s: (0, ['env', 'NDCHEF=mongo_backup',...

したがって、タスクを受け入れ、タスクを実行し、ANOTHER QUEUE ENTIRELY で ANOTHER ワーカーをトリガーして、適切に戻るのではなく、AT THE SAME TIME に実行します。私が考えることができる唯一のことは、このワーカーが正しいソースを持つ唯一のワーカーであるということです。他のすべてのワーカーは、サブプロセス呼び出しがコメント化された古いソースを持っているため、多かれ少なかれ即座に戻ります。

何が原因なのか誰にもわかりませんか？これは、セロリ キューから 3 つのランダムなマシンを選択して実行するように見えるため、これが発生した唯一のタスクではありません。これを引き起こした可能性のある celeryconfig で行った奇妙なことはありますか?

4

1 に答える 1

1

TaskPool ログは、明示的なルーティングがないことを示唆しています。routing_key とデフォルトの「exchange」を参照してください。

'delivery_info': {'priority': None, 'routing_key': u'', 'exchange': u'celery'}

問題は、すぐに使える自動デフォルトです。セロリ構成で明示的な手動ルーティングをテストすることを検討してください。

http://docs.celeryproject.org/en/latest/userguide/routing.html#manual-routing

例えば：

CELERY_ROUTES = {
"work-queue": {
    "queue": "work_queue",
    "binding_key": "work_queue"
},
"new-feeds": {
    "queue": "new_feeds",
    "binding_key": "new_feeds"
},
}

CELERY_QUEUES = {
"work_queue": {
    "exchange": "work_queue",
    "exchange_type": "direct",
    "binding_key": "work_queue",
},
"new_feeds": {
    "exchange": "new_feeds",
    "exchange_type": "direct",
    "binding_key": "new_feeds"
},
}
于 2013-05-17T00:57:53.207 に答える