2017-01-18 9 views
5

ブローカーに送信された後に私の仕事の一部が落ちてしまうという奇妙な問題が発生しています。これは、約10のタスクのうちの1つに対して発生します。私は古いセロリ労働者が仕事を消費していないことを確認しました。rabbitmqブローカーに送信した後にセロリの仕事が失われました

データベースバックエンドとフラワーを使用して不足しているタスクを監視しましたが、apply_asyncの後に返されたtask_idはデータベースまたは花には存在しません。その状態は常に保留状態になります。

次に、セロリ信号を使って何が起きているのかを調べました。私は欠けている仕事のために、before_task_publishとafter_task_publish信号だけが発射されることを発見しました。この仕事のための跡がないことを伝える。

これらは私の信号

@before_task_publish.connect 
def before_task_publish_handler(sender=None, headers=None, body=None, **kwargs): 
# information about task are located in headers for task messages 
# using the task protocol version 2. 
    logger.info("BEFORE TASK SENT id:"+body['id']) 



@after_task_publish.connect 
def after_task_publish_handler(sender=None, headers=None, body=None, exchange=None, routing_key=None, **kwargs): 
# information about task are located in headers for task messages 
# using the task protocol version 2. 
    logger.info("AFTER TASK SENT id:"+body['id']) 


@task_prerun.connect 
def task_prerun_handler(sender=None, task_id=None, task=None, **kwargs): 
    logger.info("TASK PRERUN with TASK_ID:"+str(task_id)) 

ある。これは、私はタスクがRabbitMQのでは無視またはその静かに何らかの理由で廃棄されているかどうかを確認していないログ

$ cat gunicorn-access.log | grep -i 103de274-00dc-4765-844f-d319e9e199c2 
    BEFORE TASK SENT id: '103de274-00dc-4765-844f-d319e9e199c2' 
    AFTER TASK SENT id: '103de274-00dc-4765-844f-d319e9e199c2' 

で見つけたものです。

+0

理由を確認しましたか? – melih

答えて

2

セカリは、実行される前にタスクを失います。紛失したくない場合は、task_acks_late(旧バージョンではCELERY_ACKS_LATE)を有効にする必要があります。あなたのセロリの設定で

は、これはタスクメッセージがafter the task has been executedを認めされることを確認します

task_acks_late = True 

を設定します。

+0

これは私の問題を解決しません。 tcpdumpはamqpパケットがrabbitmqサーバに送信されているが、他端には受信されたパケットがないことを示しています。クライアントとサーバーは異なるAzureアカウントにあります。 AzureのTCP接続タイムアウト設定が影響を受けるかもしれませんが、キープアライブまたはハートビートを使用しても解決できませんでした。 – melih

関連する問題