ruby on rails - rails - sondeo con delayed_job

sidekiq perform now

Question

Tengo un proceso que generalmente tarda unos segundos en completarse, así que estoy tratando de usar el método de retraso para manejarlo de forma asincrónica. El trabajo en sí funciona bien, mi pregunta es cómo hacer una encuesta sobre el trabajo para saber si está hecho.

Puedo obtener una identificación de delayyed_job simplemente asignándola a una variable:

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-... |
+------+----------+----------+------------+------------+-------------+-----------+-----------+-----------+------------+-------------+

Pero tan pronto como completa el trabajo, lo elimina y la búsqueda del registro completado devuelve un error:

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

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

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

¿Debo molestarme en cambiar esto y quizás posponer la eliminación de registros completos? No estoy seguro de qué otra forma puedo recibir una notificación de su estado. O está sondeando un registro muerto como prueba de que está bien? ¿Alguien más enfrenta algo similar?

Answer 1

Comencemos con la API. Me gustaría tener algo como lo siguiente.

@available.working? # => true or false, so we know it''s running
@available.finished? # => true or false, so we know it''s finished (already ran)

Ahora vamos a escribir el trabajo.

class AwesomeJob < Struct.new(:options)

  def perform
    do_something_with(options[:var])
  end

end

Hasta aquí todo bien. Tenemos un trabajo. Ahora vamos a escribir la lógica que lo enquista. Dado que Available es el modelo responsable de este trabajo, vamos a enseñarle cómo comenzar este trabajo.

class Available < ActiveRecord::Base

  def start_working!
    Delayed::Job.enqueue(AwesomeJob.new(options))
  end

  def working?
    # not sure what to put here yet
  end

  def finished?
    # not sure what to put here yet
  end

end

Entonces, ¿cómo sabemos si el trabajo está funcionando o no? Hay algunas maneras, pero en los rieles parece correcto que cuando mi modelo crea algo, generalmente se asocia con ese algo. ¿Cómo nos asociamos? Usando identificadores en la base de datos. job_id un job_id en el modelo Disponible.

Mientras estamos en eso, ¿cómo sabemos que el trabajo no está funcionando porque ya terminó, o porque aún no comenzó? Una forma es verificar realmente qué hizo realmente el trabajo. Si creó un archivo, verifique si el archivo existe. Si calculó un valor, verifique que el resultado esté escrito. Sin embargo, algunos trabajos no son tan fáciles de verificar, ya que es posible que no haya un resultado claro verificable de su trabajo. Para tal caso, puede usar una bandera o una marca de tiempo en su modelo. Suponiendo que este sea nuestro caso, agreguemos una marca de tiempo job_finished_at para distinguir un trabajo que aún no se ejecutó de uno ya terminado .

class AddJobIdToAvailable < ActiveRecord::Migration
  def self.up
    add_column :available, :job_id, :integer
    add_column :available, :job_finished_at, :datetime
  end

  def self.down
    remove_column :available, :job_id
    remove_column :available, :job_finished_at
  end
end

Bien. Así que, en realidad, start_working! Available con su trabajo tan pronto como pongamos en cola el trabajo, modificando el start_working! método.

def start_working!
  job = Delayed::Job.enqueue(AwesomeJob.new(options))
  update_attribute(:job_id, job.id)
end

Estupendo. En este punto, podría haber escrito belongs_to :job , pero realmente no necesitamos eso.

¿Entonces ahora sabemos cómo escribir el working? método, tan fácil.

def working?
  job_id.present?
end

¿Pero cómo marcamos el trabajo terminado? Nadie sabe que un trabajo ha terminado mejor que el trabajo en sí. Pasemos, por lo tanto, available_id al trabajo (como una de las opciones) y úselo en el trabajo. ¡Para eso tenemos que modificar el start_working! método para pasar la identificación.

def start_working!
  job = Delayed::Job.enqueue(AwesomeJob.new(options.merge(:available_id => id))
  update_attribute(:job_id, job.id)
end

Y deberíamos agregar la lógica en el trabajo para actualizar nuestra job_finished_at tiempo job_finished_at cuando esté lista.

class AwesomeJob < Struct.new(:options)

  def perform
    available = Available.find(options[:available_id])
    do_something_with(options[:var])

    # Depending on whether you consider an error''ed job to be finished
    # you may want to put this under an ensure. This way the job
    # will be deemed finished even if it error''ed out.
    available.update_attribute(:job_finished_at, Time.current)
  end

end

Con este código en su lugar, ¿sabemos cómo escribir nuestro finished? método.

def finished?
  job_finished_at.present?
end

Y terminamos. Ahora podemos simplemente sondear contra @available.working? y @available.finished? Además, obtiene la conveniencia de saber qué trabajo exacto se creó para su Disponible al marcar @available.job_id . Puede convertirlo fácilmente en una asociación real diciendo belongs_to :job .

Answer 2

Creo que la mejor manera sería usar las devoluciones de llamada disponibles en el trabajo demorado. Estos son:: éxito,: error y: después. para que pueda poner un código en su modelo con el después:

class ToBeDelayed
  def perform
    # do something
  end

  def after(job)
    # do something
  end
end

Porque si insiste en utilizar el método obj.delayed.thethod, tendrá que aplicar el parche monkey Delayed :: PerformableMethod y agregar allí el método after . En mi humilde opinión, es mucho mejor que la votación por algún valor que incluso podría ser específico para el back-end (ActiveRecord vs. Mongoid, por ejemplo).

Answer 3

El método más simple de lograr esto es cambiar su acción de sondeo para que sea similar a lo siguiente:

def poll
  @job = Delayed::Job.find_by_id(params[:job_id])

  if @job.nil?
    # The job has completed and is no longer in the database.
  else
    if @job.last_error.nil?
      # The job is still in the queue and has not been run.
    else
      # The job has encountered an error.
    end
  end
end

¿Por qué funciona esto? Cuando Delayed::Job ejecuta un trabajo desde la cola, lo elimina de la base de datos si tiene éxito . Si el trabajo falla, el registro permanece en la cola para volver a ejecutarse más tarde y el atributo last_error se establece en el error encontrado. Con las dos funciones anteriores, puede verificar los registros eliminados para ver si tuvieron éxito.

Los beneficios del método anterior son:

• Obtienes el efecto de encuesta que estabas buscando en tu publicación original
• Usando una rama de lógica simple, puede proporcionar comentarios al usuario si hay un error al procesar el trabajo

Puede encapsular esta funcionalidad en un método modelo haciendo algo como lo siguiente:

# Include this in your initializers somewhere
class Queue < Delayed::Job
  def self.status(id)
    self.find_by_id(id).nil? ? "success" : (job.last_error.nil? ? "queued" : "failure")
  end
end

# Use this method in your poll method like so:
def poll
    status = Queue.status(params[:id])
    if status == "success"
      # Success, notify the user!
    elsif status == "failure"
      # Failure, notify the user!
    end
end

Answer 4

La tabla delayed_jobs en su aplicación está destinada a proporcionar el estado de trabajos en ejecución y puestos en cola solamente. No es una tabla persistente, y realmente debe ser lo más pequeña posible por motivos de rendimiento. Es por eso que los trabajos se eliminan inmediatamente después de la finalización.

En su lugar, debe agregar campo a su modelo Available que indique que el trabajo está hecho. Como normalmente estoy interesado en cuánto tarda el trabajo en procesarse, agrego los campos start_time y end_time. Entonces mi método de dosomething sería algo como esto:

def self.dosomething(model_id)

 model = Model.find(model_id)

  begin
    model.start!

    # do some long work ...

    rescue Exception => e
      # ...
    ensure
      model.finish!
  end
end

¡El comienzo! ¡y acaba! los métodos simplemente registran la hora actual y guardan el modelo. Entonces, ¿tendría una completed? método que su AJAX puede sondear para ver si el trabajo está terminado.

def completed?
  return true if start_time and end_time
  return false
end

Hay muchas formas de hacerlo, pero considero que este método es simple y funciona bien para mí.

Answer 5

Sugeriría que, si es importante recibir una notificación de que el trabajo se ha completado, escriba un objeto de trabajo personalizado y haga cola en lugar de confiar en el trabajo predeterminado que se pone en cola cuando llama a Available.delay.dosomething . Crea un objeto como:

class DoSomethingAvailableJob

  attr_accessor options

  def initialize(options = {})
    @options = options
  end

  def perform
    Available.dosomething(@options)
    # Do some sort of notification here
    # ...
  end
end

y enquéue con:

Delayed::Job.enqueue DoSomethingAvailableJob.new(:var => 1234)

Answer 6

Terminé usando una combinación de Delayed_Job con una devolución de llamada posterior a (trabajo) que rellena un objeto memcached con el mismo ID que el trabajo creado. De esta forma, minimizo el número de veces que llegué a la base de datos para conocer el estado del trabajo, en lugar de eso, sondeé el objeto que se ha archivado. Y contiene el objeto completo que necesito del trabajo completo, por lo que ni siquiera tengo una solicitud de ida y vuelta. Obtuve la idea de un artículo de los chicos de Github que hicieron más o menos lo mismo.

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

y usó un plugin jquery para el sondeo, que sondea con menos frecuencia, y se da por vencido después de un cierto número de intentos

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

Parece que funciona bien.

 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