Django 芹菜任务结果尽管成功但未返回

我正在尝试使用django+芹菜+django+rabbitmq+memcached将同步任务卸载到其他服务器

根据芹菜日志和芹菜花，异步任务被发送到工作者并成功执行。然而，结果似乎永远不会回来

在web服务器上运行的代码是：

def wait_task(task, *args):
    async_result = task.delay(*args)
    return async_result.get()

@shared_task(serializer="pickle")
def render_pdf(pdf_id):
    pdf = do_stuff()
    return pdf

pdf = wait_task(render_pdf, pdf_id)

我的

BROKER\u URL

设置为

librabbitmq://guest:guest@172.17.0.5:5672/

，芹菜日志和芹菜花产量证明了这一点

芹菜花中显示的截断结果让人想起成功渲染的PDF

/etc/rabbitmq/rabbitmq env.conf

是：

NODENAME=rabbit@localhost
NODE_IP_ADDRESS=0.0.0.0

我不确定下一步该去哪里。假设芹菜没有返回/调用rabbitmq，或者rabbitmq没有返回/调用原始wait_任务调用

但是，如果我在与代理相同的VM上运行web服务器，那么即使使用相同的代理URL，一切都可以正常工作。在配置中的某个地方，我想它正在假设回调到哪里，比如localhost/127.0.0.1或其他什么

更新1：

从启动到第一次共享任务完成的芹菜日志输出：

[2016-02-02 23:54:07,786: DEBUG/MainProcess] | Worker: Preparing bootsteps.
[2016-02-02 23:54:07,792: DEBUG/MainProcess] | Worker: Building graph...
[2016-02-02 23:54:07,793: DEBUG/MainProcess] | Worker: New boot order: {StateDB, Timer, Hub, Queues (intra), Pool, Autoreloader, Beat, Autoscaler, Consumer}
[2016-02-02 23:54:07,796: DEBUG/MainProcess] | Consumer: Preparing bootsteps.
[2016-02-02 23:54:07,797: DEBUG/MainProcess] | Consumer: Building graph...
[2016-02-02 23:54:07,799: DEBUG/MainProcess] | Consumer: New boot order: {Connection, Events, Mingle, Gossip, Tasks, Control, Agent, Heart, event loop}
[2016-02-02 23:54:07,806: DEBUG/MainProcess] | Worker: Starting Hub
[2016-02-02 23:54:07,807: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:07,807: DEBUG/MainProcess] | Worker: Starting Pool
[2016-02-02 23:54:07,811: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:07,813: DEBUG/MainProcess] | Worker: Starting Autoscaler
[2016-02-02 23:54:07,813: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:07,814: DEBUG/MainProcess] | Worker: Starting Consumer
[2016-02-02 23:54:07,815: DEBUG/MainProcess] | Consumer: Starting Connection
[2016-02-02 23:54:07,824: INFO/MainProcess] Connected to amqp://guest:**@172.17.0.5:5672//
[2016-02-02 23:54:07,825: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:07,826: DEBUG/MainProcess] | Consumer: Starting Events
[2016-02-02 23:54:07,836: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:07,837: DEBUG/MainProcess] | Consumer: Starting Mingle
[2016-02-02 23:54:07,838: INFO/MainProcess] mingle: searching for neighbors
[2016-02-02 23:54:08,848: INFO/MainProcess] mingle: all alone
[2016-02-02 23:54:08,850: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:08,851: DEBUG/MainProcess] | Consumer: Starting Gossip
[2016-02-02 23:54:08,855: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:08,856: DEBUG/MainProcess] | Consumer: Starting Tasks
[2016-02-02 23:54:08,862: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:08,863: DEBUG/MainProcess] | Consumer: Starting Control
[2016-02-02 23:54:08,867: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:08,868: DEBUG/MainProcess] | Consumer: Starting Heart
[2016-02-02 23:54:08,870: DEBUG/MainProcess] ^-- substep ok
[2016-02-02 23:54:08,871: DEBUG/MainProcess] | Consumer: Starting event loop
[2016-02-02 23:54:08,873: DEBUG/MainProcess] /virtualenv/processing/local/lib/python2.7/site-packages/celery/fixups/django.py:265: UserWarning: Using settings.DEBUG leads to a memory leak, never use this setting in production environments!
  warnings.warn('Using settings.DEBUG leads to a memory leak, never '
[2016-02-02 23:54:08,875: DEBUG/MainProcess] worker-1@172.17.0.5 ready.
[2016-02-02 23:54:08,876: DEBUG/MainProcess] | Worker: Hub.register Autoscaler...
[2016-02-02 23:54:08,877: DEBUG/MainProcess] | Worker: Hub.register Pool...
[2016-02-02 23:54:08,878: DEBUG/MainProcess] basic.qos: prefetch_count->1
[2016-02-02 23:54:13,263: INFO/MainProcess] Received task: tasks.render_pdf[149cc075-1d09-4547-86ee-57608c1df8aa]
[2016-02-02 23:54:13,265: DEBUG/MainProcess] TaskPool: Apply <function _fast_trace_task at 0x7f08fccd7488> (args:('tasks.render_pdf', '149cc075-1d09-4547-86ee-57608c1df8aa', (u'en', 8583L), {}, {'utc': True, u'is_eager': False, 'chord': None, u'group': None, 'args': (u'en', 8583L), 'retries': 0, u'delivery_info': {u'priority': None, u'redelivered': False, u'routing_key': 'default', u'exchange': 'default'}, 'expires': None, u'hostname': 'worker-1@172.17.0.5', 'task': 'tasks.render_pdf', 'callbacks': None, u'correlation_id': '149cc075-1d09-4547-86ee-57608c1df8aa', 'errbacks': None, 'timelimit': (None, None), 'taskset': None, 'kwargs': {}, 'eta': None, u'reply_to': '8502acac-0475-3f84-b542-03fdf4ea4d3d', 'id': '149cc075-1d09-4547-86ee-57608c1df8aa', u'headers': {}}) kwargs:{})
[2016-02-02 23:54:13,267: DEBUG/MainProcess] Task accepted: tasks.render_pdf[149cc075-1d09-4547-86ee-57608c1df8aa] pid:5033
[2016-02-02 23:54:14,193: INFO/MainProcess] Task tasks.render_pdf[149cc075-1d09-4547-86ee-57608c1df8aa] succeeded in 0.926254872s: '%PDF-1.4\n1 0 obj\n<<\n/Title (\xfe\xff\x00T\x00i\x00c\x00k\x00e\x00t\x00f\x00l\x00a\x00p\x00...

更新3：

在

/var/logs/rabbitmq中输出/rabbitmq@localhost.log

：

如果我在不同的实例上运行芹菜和web服务器，其故障如下：

=INFO REPORT==== 2-Feb-2016::16:12:33 ===
accepting AMQP connection <0.469.0> (172.17.0.6:36786 -> 172.17.0.5:5672)

=信息报告===2016年2月2日：：16:12:33===
接受AMQP连接（172.17.0.6:36786->172.17.0.5:5672）

如果我在同一个实例上运行芹菜和web服务器，效果很好：

=INFO REPORT==== 2-Feb-2016::16:13:09 ===
accepting AMQP connection <0.482.0> (172.17.0.5:33863 -> 172.17.0.5:5672)

=信息报告===2016年2月2日：：16:13:09===
接受AMQP连接（172.17.0.5:33863->172.17.0.5:5672）

我之前的期望是结果将通过rabbitmq返回，而不是直接通过memcached返回

公开端口11211并更改memcached config以侦听0.0.0.0修复了此问题：

在

/etc/memcached.conf

中设置

-l

，如下所示：

# -l 127.0.0.1
-l 0.0.0.0

---

你的芹菜结果后端设置是什么？芹菜本身会打印任何东西给控制台吗？尝试在打开日志以进行调试的情况下启动它。@AlexMorozov Cellery正在将调试输出到日志。看不到任何错误或任何相关内容，但我会用输出更新OP。@dm03514忘了我也在使用DjCellery作为后端，用缓存设置更新了OP。看起来您的结果后端配置有误。

# -l 127.0.0.1
-l 0.0.0.0