用delay_job轮询 [英] polling with delayed_job

查看:60
本文介绍了用delay_job轮询的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个过程通常需要花费几秒钟来完成,因此我尝试使用delay_job异步处理它.这项工作本身运行良好,我的问题是如何对工作进行轮询以了解是否完成.

I have a process which takes generally a few seconds to complete so I'm trying to use delayed_job to handle it asynchronously. The job itself works fine, my question is how to go about polling the job to find out if it's done.

我可以通过简单地将其分配给变量来从delay_job中获取ID:

I can get an id from delayed_job by simply assigning it to a variable:

job = Available.delay.dosomething(:var => 1234)

job = Available.delay.dosomething(:var => 1234)

+------+----------+----------+------------+------------+-------------+-----------+-----------+-----------+------------+-------------+
| id   | priority | attempts | handler    | last_error | run_at      | locked_at | failed_at | locked_by | created_at | updated_at  |
+------+----------+----------+------------+------------+-------------+-----------+-----------+-----------+------------+-------------+
| 4037 | 0        | 0        | --- !ru... |            | 2011-04-... |           |           |           | 2011-04... | 2011-04-... |
+------+----------+----------+------------+------------+-------------+-----------+-----------+-----------+------------+-------------+

但是一旦完成作业,它就会将其删除,并搜索完成的记录会返回错误:

But as soon as it completes the job it deletes it and searching for the completed record returns an error:

@job=Delayed::Job.find(4037)

ActiveRecord::RecordNotFound: Couldn't find Delayed::Backend::ActiveRecord::Job with ID=4037

@job= Delayed::Job.exists?(params[:id])

我是否应该对此进行更改,或者推迟完整记录的删除?我不确定如何还能收到有关其状态的通知.还是轮询无效记录作为完成证据可以吗?还有其他人面临类似的事情吗?

Should I bother to change this, and maybe postpone the deletion of complete records? I'm not sure how else I can get a notification of it's status. Or is polling a dead record as proof of completion ok? Anyone else face something similar?

推荐答案

我最终使用了Delayed_Job与after(job)回调的组合,该回调以与创建的作业相同的ID填充内存缓存对象.这样,我可以最大程度地减少访问数据库以询问作业状态的次数,而无需轮询memcached对象.它包含完成工作所需的全部对象,因此我什至没有往返请求.我从github伙计们的一篇文章中得到了这个想法,他们做了几乎相同的事情.

I ended up using a combination of Delayed_Job with an after(job) callback which populates a memcached object with the same ID as the job created. This way I minimize the number of times I hit the database asking for the status of the job, instead polling the memcached object. And it contains the entire object I need from the completed job, so I don't even have a roundtrip request. I got the idea from an article by the github guys who did pretty much the same thing.

https://github.com/blog/467-smart-js-polling

并使用了一个jquery插件进行轮询,轮询的频率降低了,并且在重试了一定次数后放弃了

and used a jquery plugin for the polling, which polls less frequently, and gives up after a certain number of retries

https://github.com/jeremyw/jquery-smart-poll

似乎工作很棒.

 def after(job)
    prices = Room.prices.where("space_id = ? AND bookdate BETWEEN ? AND ?", space_id.to_i, date_from, date_to).to_a
    Rails.cache.fetch(job.id) do
      bed = Bed.new(:space_id => space_id, :date_from => date_from, :date_to => date_to, :prices => prices)
    end
  end

这篇关于用delay_job轮询的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆