在Heroku环境中调用芹菜任务

gen*_*tro 7 django heroku celery django-celery

我在Heroku上有一个Django应用程序,它使用Celery的延迟方法调用一个任务,该方法应该将额外的处理传递给一个worker.但是当我向相应的视图发出http请求时,Heroku web dyno会挂起并最终导致请求超时.这是一个测试任务(应用程序称为等待时间):

@task
def test_tasks(message, name='waittimes.tasks.test_tasks'):
    print message
Run Code Online (Sandbox Code Playgroud)

而测试视图:

class TaskTest(View):
    def get(self, request):
        print "about to call the task"
        test_tasks.delay("the task was successful!")
        return HttpResponse("view was successful")
Run Code Online (Sandbox Code Playgroud)

如果我向这个视图发出http请求,我希望"任务成功"输出到控制台并回复说"视图成功".当我向计算机上的开发服务器发出请求时,这种情况会成功发生.如果我在我的应用程序的Heroku环境中启动django shell并使用django的测试客户端发出请求,它也可以工作.

app[celeryd.1]: [2013-06-26 23:57:48,018: INFO/MainProcess] Got task from broker: waittimes.tasks.test_tasks[67036069-b49e-45ba-aef4-3c64d7161a67]
app[celeryd.1]: [2013-06-26 23:57:48,133: WARNING/PoolWorker-3] the task was successful!
app[celeryd.1]: [2013-06-26 23:57:48,200: INFO/MainProcess] Task waittimes.tasks.test_tasks[67036069-b49e-45ba-aef4-3c64d7161a67] succeeded in 0.09690284729s: None
Run Code Online (Sandbox Code Playgroud)

但是当我直接向Heroku url发出请求时,请求会挂起,我最终会从Heroku获得一个可怕的H12超时错误.

heroku[router]: at=error code=H12 desc="Request timeout" method=GET path=/task/test/ dyno=web.1 connect=2ms service=30000ms status=503 bytes=0
Run Code Online (Sandbox Code Playgroud)

我知道调用该任务导致问题,因为"即将调用任务"确实打印在控制台中.所以问题是系统无法解析"延迟"(和apply_async)方法.它只是挂起并且不返回异步对象.这只有在代码在web dyno进程上运行时才会发生.

到目前为止,这些是我的结论:

1)任务正确注册并且我的Redis代理正在工作,因为当我使用shell中的测试客户端调用视图时一切正常(但是这是在Heroku上的单独shell进程上运行,而不是通常接收请求的web dyno )

2)系统正确地路由和调度请求的处理程序,因为"即将调用任务"被打印.它似乎不是Heroku路由器的问题.

3)问题与特定视图无关,因为即使像这样的精简测试用例也不起作用

除了直接的解决方案,任何有关如何进一步调试的建议也值得赞赏.

M. *_*yan 2

好吧,这可能不是一个直接的答案,但考虑到这个问题的存在时间以及它在无人关注的情况下持续了多长时间,我将继续为那些像我一样不幸遇到这个问题的人提供我的见解。

这个特殊的问题似乎记录很少,而且很难搜索,我只是在 Heroku 上兴建一个业余项目时遇到了这个问题。

Heroku 似乎存在一些特有的现象,即某些 Python 函数调用在平台上的行为与本地(或在任何正常的 Python 部署上)不同。

就我而言,这里的问题是我的 Celery 任务正在调用 Python 的time.sleep()函数。

作为一个测试用例,我time.sleep(1)只是在日志中演示该任务确实是异步执行的。我已在普通基础设施(包括虚拟机)上成功运行此测试多次。

当我将此测试移植到 Heroku 时,我遇到了与 gentro 完全相同的问题。日志清楚地表明 Celery 和我的代理已正常初始化,并且知道我的应用程序,但是,当我通过 Django 视图进行调用时,我的 Web dyno 会神秘地超时,并且 H12 作为唯一的日志消息。

当我注释掉该sleep电话时,一切都完全正常。

TL;DR - 检查导致 celery 任务的调用堆栈,确保您没有留下任何可能导致 Heroku dyno 停止运行的函数,例如sleep()

我并不是说这就是导致原始提问者问题的具体原因,但如果您看到这种行为,这绝对是潜在原因之一。