从内部重新排队或评估延迟的工作？ [英] Requeue or evaluate delayed job from inside?

问题描述

是否可以从作业任务本身内部确定正在运行的 delayed_job 作业的状态？我有一个工作要与非常不稳定的服务交互，并且对于某些类型的连接失败，我想重新排队该工作，并且仅当在重试限制下再次发生连接失败时才引发异常。

Is there a way to determine the status of a running delayed_job job from inside the job task itself? I have a job that interacts with a service that can be pretty flaky and for a certain class of connection failures I'd like to requeue the job and only raise an exception if a connection failure occurs again at the retry limit.

伪代码演示我想要执行的操作：

Pseudo-code to demonstrate what I want to be able to do:

def do_thing
  service.send_stuff(args)
rescue Exception1, Exception2
  if job.retries == JOBS_MAX
    raise
  else
    job.requeue
  end
end

我不想对任何失败提出例外，因为通常这项工作将在以后的重试中完成，这只是在吵闹我。我要做想知道它是否从未完成。

I don't want to raise an exception on any failure because generally the job will be completed okay on a later retry and it is just making noise for me. I do want to know if it is never completed, though.

推荐答案

如您所说，如果延迟的作业运行器到达性能队列的末尾，则它将被视为成功运行并从队列中删除。因此，您只需要阻止它就结束。没有排队-即使有一条具有新属性的新记录。因此，您可能会重新考虑导致作业通知您异常的任何原因。例如，您可以添加条件以通知您……

As you've said, if the Delayed Job runner gets to the end of the perform queue then it will be considered as a successful run and removed from the queue. So you just have to stop it from getting to the end. There isn't a requeue -- even if there was it'd be a new record with new attributes. So you may rethink whatever it is that is causing the job to notify you about exceptions. You could, for example, add a condition upon which to notify you...

潜在解决方案

您可以使用 Delayed :: Worker.max_attempts JOBS_MAX （伪编码）。 $ c>，也可以通过定义方法来设置自己的每项工作，例如： max_attempts 。

You can get the default JOBS_MAX (as you pseudo-coded it) with Delayed::Worker.max_attempts or you can set your own per-job by defining a method, e.g.: max_attempts.

# Fail permanently after the 10th failure for this job
def max_attempts
  10
end

也就是说，鉴于以下情况，该方法将可用：

That is, this method will be usable given the following:

您还可以使用回调钩子。延迟的作业将通过错误方法（如果已定义）回调到您的有效负载对象。因此，您可以使用 error 方法来通知您超出给定尝试次数的实际异常。为此...

You can also make use of callback hooks. Delayed Job will callback to your payload object via the error method if it is defined. So you may be able to use the error method to notify you of actual exceptions beyond a given attempt number. To do that...

在回调中，将Delayed :: Job对象本身作为第一个参数返回：

Within the callback, the Delayed::Job object itself is returned as the first argument:

def error(job, exception)
  job.attempts # gives you the current attempt number
  # If job.attempts is greater than max_attempts then send exception notification
  # or whatever you want here...
end

所以您可以使用回调开始在何时通知自己和何时不通知自己上添加逻辑。我什至建议您创建一个基本功能集，将其包含在所有有效负载对象中以执行这些操作……但这取决于您和您的设计。

So you can use the callbacks to start adding logic on when to notify yourself and when not to. I might even suggest making a base set of functionality that you can include into all of your payload objects to do these things... but that's up to you and your design.

这篇关于从内部重新排队或评估延迟的工作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！