吸盘冲击工作被乘客杀死？还是死锁？

Question

想知道是否有人看到过这个问题.我正在使用sucker_punch gem版本1.1在Passenger 3上运行Rails 3.2

我有一个长期运行的sucker_punch工作(大约需要10个小时)这是一个整夜的批次.我在Phusion Passenger上运行(我认为3个工作线程)

status from passenger-status
----------- General information -----------
max = 3
count = 0
active = 0
inactive = 0
Waiting on global queue: 0

我的sucker_punch作业执行异步,作为其执行其他异步较小的sucker_punch作业的作业的一部分(每个约需30秒)

我无法准确地确定发生了什么,但"有时"我的长期工作刚刚死亡或似乎停止了.我确实在整个sucker_punch作业中添加了一些调试代码

begin
rescue Exception => e
  logger.error(e)
  raise e
end

但是没有看到异常,那么假设我的长时间运行sucker_punch正在停止而不是被杀死？还是潜在的某种僵局？

这个有趣的部分.有时我的长期工作运作良好,有时却没有.

Answer 1

这是对的.目前,Passenger假定您的流程仅处理Web请求,而不是后台任务.因此,Passenger强制执行某些限制,以便控制错误的应用程序.其中一个限制是,如果指示一个过程关闭,它必须在1分钟内完成; 如果没有,乘客将强行关闭.不幸的是,这与在app进程中运行后台任务的概念本质上是不兼容的.

也许我们将来会对此进行研究,但现在它不被视为高优先级项目.我建议你使用一个进程外的后台工作系统,比如Sidekiq.