3

想知道有没有人看到这个问题。我正在使用 Sucker_punch gem 版本 1.1 在乘客 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 正在停止而不是被杀死？或者潜在的某种僵局？

这其中有趣的部分。有时我的长期工作运行良好，有时却不行。

4

1 回答 1

5

这是对的。目前，Passenger 假设您的进程只处理 Web 请求，而不是后台任务。正因为如此，Passenger 强制执行某些限制，以控制有缺陷的应用程序。其中一个限制是，如果一个进程被指示关闭，它必须在 1 分钟内完成；如果没有，Passenger 将强制它关闭。不幸的是，这本质上与在应用程序进程中运行后台任务的概念不兼容。

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

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

于 2014-07-12T21:31:54.917 回答