Python 如何在Cloud Foundry上与芹菜沟通？

我有一个带有芹菜组件的wsgi应用程序。基本上，当某些请求进来时，他们可以将相对耗时的任务交给芹菜。我在自己设置的服务器上有一个该产品的工作版本，但我们的客户最近要求我将其部署到Cloud Foundry。由于芹菜在Cloud Foundry上不能作为服务提供，我们（我和客户的部署团队）决定部署该应用两次——一次作为wsgi应用，一次作为独立芹菜应用，共享rabbitmq服务

应用程序之间的代码是相同的。wsgi应用程序正确响应，返回预期的网页

vmc logs celeryapp

显示celery将启动并运行，但当我向wsgi发送应成为celery任务的请求时，它们会在到达

.delay（）

语句时立即消失。它们既不会出现在芹菜日志中，也不会显示为错误

尝试调试：

• 我不能在Cloud Foundry中使用

  芹菜.contrib.rdb

  （为pdb提供telnet接口），因为每个应用程序都是沙盒和端口限制的
• 我不知道如何找到这些应用程序应该共享的特定rabbitmq实例，因此我可以看到它传递的消息

更新：为了证实上述关于查找rabbitmq的说法，以下是当我尝试访问应该共享芹菜任务的节点时发生的情况：

root@cf:~# export RABBITMQ_NODENAME=eecef185-e1ae-4e08-91af-47f590304ecc
root@cf:~# export RABBITMQ_NODE_PORT=57390
root@cf:~# ~/cloudfoundry/.deployments/devbox/deploy/rabbitmq/sbin/rabbitmqctl list_queues
Listing queues ...

=ERROR REPORT==== 18-Jun-2012::11:31:35 ===
Error in process <0.36.0> on node 'rabbitmqctl17951@cf' with exit value: {badarg,[{erlang,list_to_existing_atom,["eecef185-e1ae-4e08-91af-47f590304ecc@localhost"]},{dist_util,recv_challenge,1},{dist_util,handshake_we_started,1}]}

Error: unable to connect to node 'eecef185-e1ae-4e08-91af-47f590304ecc@cf': nodedown
diagnostics:
- nodes and their ports on cf: [{'eecef185-e1ae-4e08-91af-47f590304ecc',57390},
                                {rabbitmqctl17951,36032}]
- current node: rabbitmqctl17951@cf
- current node home dir: /home/cf
- current node cookie hash: 1igde7WRgkhAea8fCwKncQ==

root@cf：~#导出RABBITMQ_NODENAME=eecef185-e1ae-4e08-91af-47f590304ecc
root@cf：~#导出RABBITMQ_节点_端口=57390
root@cf：~~#~/cloudfoundry/.deployments/devbox/deploy/rabbitmq/sbin/rabbitmqctl list\u队列
正在列出队列。。。
=错误报告===2012年6月18日：：11:31:35===
节点“”上的进程出错rabbitmqctl17951@cf'的退出值：{badarg，[{erlang，list_to_existing_atom，[“eecef185-e1ae-4e08-91af-47f590304ecc@localhost“]}，{dist_util，recv_challenge，1}，{dist_util，我们开始握手，1}]}
错误：无法连接到节点“eecef185-e1ae-4e08-91af”-47f590304ecc@cf’：点头
诊断：
-cf:[{'eecef185-e1ae-4e08-91af-47f590304ecc'，57390}上的节点及其端口，
{RabbitMQCTL1795136032}]
-当前节点：rabbitmqctl17951@cf
-当前节点主目录：/home/cf
-当前节点cookie哈希：1igde7WRgkhAea8fCwKncQ==

---

我如何调试这个和/或为什么我的任务消失了

显然，问题是由代理和芹菜工人之间的死锁引起的，因此工人永远不会承认任务已完成，也不会接受新任务，但也不会崩溃或失败。任务并没有消失；他们只是永远排队

---

更新：死锁是由于我们在安装了依赖项的包装器脚本中运行celeryd造成的。（字面意思是

pip安装-r requirements.txt&&./celeryd-lINFO

）。由于Cloud Foundry管理进程树的方式，Cloud Foundry会试图杀死父进程（bash），这会使celeryd崩溃，但最终很多子进程都不会死。

显然，问题是由代理和celery worker之间的死锁引起的，这样，工作人员将永远不会承认任务已完成，也不会接受新任务，但也不会崩溃或失败。任务并没有消失；他们只是永远排队

更新：死锁是由于我们在安装了依赖项的包装器脚本中运行celeryd造成的。（字面意思是

pip安装-r requirements.txt&&./celeryd-lINFO

）。由于Cloud Foundry是如何管理进程树的，Cloud Foundry会试图杀死父进程（bash），这会使celeryd崩溃，但最终很多子进程都不会死