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

Question

想知道是否有人见过这个问题。 我正在使用sucker_punch gem version 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秒）

我无法确切地确定发生了什么，但有时候＆＃39;我的长期工作刚刚去世或似乎停止了。 我确实在整个sucker_punch作业中添加了一些调试代码

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

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

这个有趣的部分。有时我的长期工作运作良好，有时它没有。

Answer 1

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

目前有一个问题：https://github.com/phusion/passenger/issues/1211

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