Windows 下使用 django/celery 时出现 WorkerLostError、Python.exe APPCRASH
我在 Windows(Win2008 Server R2、IIS 7.5、MS SQL)下设置了 Django。我正在尝试实现 celery 2.4.1(使用 RabbitMQ)来进行任务处理,但遇到了一个非常令人沮丧的问题。
我用推荐的启动 celeryd:
manage.py celeryd --settings=settings
并且运行正常。然后在我的 django 项目中,我触发一个任务来启动(为了测试,我只是使用简单的“添加”示例:
@task
def add(x, y):
return x + y
这在我的views.py中被称为:
tasks.add.delay(1,2)
当celeryd选择这个时,会发生一些事情,< em>有时: 1) 我收到一个 Windows 对话框,“python.exe 已停止工作”,以及关闭它的选项。 2)关闭之后,在运行 celeryd 的 cmd 中,我得到:
[date-time: ERROR/MainProcess] Task [taskUUID] raised exception: WorkerLostError('Worker exited prematurely.',)
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\celery\concurrency\processes\pool.py", line 610, in _join_exited_workers
raise WorkerLostError("Worker exited prematurely.")
WorkerLostError: Worker exited prematurely.
我已经尝试过非常繁琐地修改几乎每个 celery 设置,一次一个,这可能会影响工作人员(CELERYD_CONCURRENCY、CELERYD_PREFETCH_MULTIPLIER、CELERYD_MAX_TASKS_PER_CHILD 等) )对此没有任何影响。
真正奇怪的是,有时,在发生这种情况之后(我只是让 celeryd 运行......它不会杀死该进程......?),我可以再次触发任务,没有 python.exe 崩溃,并且任务将成功完成。
我来自 settings.py 的与 celery 相关的设置:
BROKER_HOST = "localhost"
BROKER_PORT = 5672
BROKER_USER = "guest"
BROKER_PASSWORD = "guest"
BROKER_VHOST = "/"
CELERY_IMPORTS = ("myproject.tasks",)
CELERY_RESULT_BACKEND = "database"
CELERY_SEND_EVENTS=True #same as '-E' option from cmd
我强烈怀疑存在 celery bug(可能特定于 Windows 实现?),但我还没有足够的能力来识别它或提出修复方案。
I have Django set up under Windows (Win2008 Server R2, IIS 7.5, MS SQL). I'm trying to implement celery 2.4.1 (with RabbitMQ) for task processing and running into a very frustrating problem.
I start celeryd with the recommended:
manage.py celeryd --settings=settings
and it runs OK. Then in my django project, I trigger a task to start (for testing I'm just using the simple "add" example:
@task
def add(x, y):
return x + y
and that's called in my views.py as:
tasks.add.delay(1,2)
When celeryd picks this up, a couple of things happen, sometimes:
1) I get a Windows dialog, "python.exe has stopped working", and an option to close it.
2) After closing that, in the cmd where celeryd is running, I get:
[date-time: ERROR/MainProcess] Task [taskUUID] raised exception: WorkerLostError('Worker exited prematurely.',)
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\celery\concurrency\processes\pool.py", line 610, in _join_exited_workers
raise WorkerLostError("Worker exited prematurely.")
WorkerLostError: Worker exited prematurely.
I've tried very tediously tinkering with just about every celery setting, one at a time, that could possibly affect workers (CELERYD_CONCURRENCY, CELERYD_PREFETCH_MULTIPLIER, CELERYD_MAX_TASKS_PER_CHILD, etc.) with no effect whatsoever on this.
What's really strange is that sometimes, after that has happened (and I just leave celeryd running...it doesn't kill that process...?), I can trigger the task again, with no python.exe crash, and the task will complete successfully.
My celery-relevant settings from settings.py:
BROKER_HOST = "localhost"
BROKER_PORT = 5672
BROKER_USER = "guest"
BROKER_PASSWORD = "guest"
BROKER_VHOST = "/"
CELERY_IMPORTS = ("myproject.tasks",)
CELERY_RESULT_BACKEND = "database"
CELERY_SEND_EVENTS=True #same as '-E' option from cmd
I strongly suspect a celery bug (possibly specific to Windows implementation?) but I don't quite have the chops yet to identify it or propose a fix.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
最后,经过几个月的断断续续的修补,我相信我已经弄清楚了。
该问题似乎来自使用 django-mssql 作为 Django 数据库引擎。 django-mssql 依赖于 pywin32,其中一个调用使用 ole32.dll 并导致崩溃,从而导致 Python 崩溃,从而出现 WorkerLostError。
我已切换到 django-pyodbc,它不使用有问题的 pywin32/ole32.dll 调用,并且自切换以来没有遇到此类无法解释的 WorkerLostError 。
Finally, after many months of tinkering on and off with this, I believe I have figured it out.
The problem appears to be coming from the use of django-mssql as the Django database engine. django-mssql relies on pywin32, and one of the calls there uses ole32.dll and causes a crash there, which consequently brings down Python, hence the WorkerLostError.
I've switched to django-pyodbc which does not use the problematic pywin32/ole32.dll call, and have not experienced an unexplained WorkerLostError such as these since switching.