Задержанные задания на Rails 2: не удается сохранить в методе «выполнить» / как узнать, когда работа выполнена?

Question

Я использую плагин Delayed Jobs для Rails 2, и каждый раз, когда я пытаюсь изменить модель и сохранить ее в методе «execute», требуемом для Delayed Jobs, он выходит из строя (никаких сообщений об ошибках или чего-то еще, это просто указан как сбой в базе данных).

У меня есть метод "execute" в одном из моих файлов моделей рельсов (Видео), и я передаю экземпляр этой модели (скажем, @video) в Delayed :: Job.enqueue

Это известная проблема, что вы не можете вносить изменения в базу данных, находясь в очереди? Я делаю что-то не так (происходит сбой только при попытке сохранить, а не когда я на самом деле изменяю атрибуты, и это звучит как проблема модификации базы данных).

Если это ожидается: как я могу это исправить? Я пытаюсь сохранить атрибут "done" в true, поэтому я знаю, когда модель готова перейти к следующему шагу. Есть ли какой-нибудь стандартный способ выяснить, когда выполняется отложенная работа?

РЕДАКТИРОВАТЬ: я подтвердил, что вызов выполнить автономно (без отложенного задания) не имеет проблем с сохранением (без ошибок или предупреждений, или что-нибудь). Когда я вызываю его через DelayedJobs, он выходит НЕМЕДЛЕННО (без тайм-аута), как только он попадает в строку сохранения.

РЕДАКТИРОВАТЬ: Подожди, я думаю, что я вижу, что происходит: мое "перформанс" является частью обратного вызова "after_create" ... Что все хорошо, пока я не попытаюсь СОХРАНИТЬ. Похоже, что когда я сохраняю, он вызывает «ВНОВЬ» (пока он уже в работе), и это не работает с отложенными заданиями (и не должно). По какой-то причине я думал, что after_create будет вызываться только один раз (не после каждого сохранения). Подождите, простой тест только что показал, что это так. Хм ... Так почему перфоманс выполняется дважды, когда я сохраняю, и один раз, когда нет, на отложенных заданиях?

Мой код:

after_create :start_transcodes

 def start_transcodes
     Delayed::Job.enqueue self  
 end
     def perform
      puts "performing"
      self.flash_status = 100
      self.save!
      puts "done"
     end

Что я вижу:

    performing
    performing
2 jobs processed at 3.3406 j/s, 2 failed ...

Я не вижу, чтобы это говорило "сделано" никогда.

В журнале рельсов я вижу:

"* [JOB] Video failed with NameError: undefined local variable or method `flush_deletes' for #<Paperclip::Attachment:0xb6e51da0> - 2 failed attempts
undefined local variable or method `flush_deletes' for #<Paperclip::Attachment:0xb6e51da0>"

Я использую плагин paperclip для этого класса, и я могу вызвать save весь день (даже в этом методе execute) и не получить никаких проблем. Я ТАКЖЕ могу вызывать save (опять же, даже во время выполнения) весь день и не видеть, как мой метод after_create вызывается более одного раза - ЕСЛИ Я не использую отложенное задание (может быть, выполняется какая-то автоматическая повторная попытка?)

Я собираюсь осмотреть мой плагин для скрепок, посмотреть, что происходит ...

Answer 1

Хорошо, точно не знаю, что именно происходило, но я сделал скелетный класс "TranscodeJob" в моей директории lib. Этот класс инициализируется со ссылкой на то, какое видео я хочу, чтобы оно обрабатывало, обрабатывало и сохраняло, а также проигрывало с отложенным заданием.

По сути, похоже, что передача всего моего сложного объекта Video (в комплекте с плагинами-скрепками) в Delayed Job приводила в бешенство, а передача простого объекта без информации, необходимой для этого, делает вещи намного проще.

Ниже приведен код, который я использовал, и он прекрасно работает (и если он работает нормально, я могу постепенно добавить свой долго работающий код и подтвердить, что он продолжает это делать, но раньше он работал нормально, просто икру )

class TranscodeJob
 def initialize(video_id)
     @video_id = video_id           
 end

 #delayed jobs expected method
 def perform
      @video = Video.find(@video_id)
      @video.flash_status = 100
      @video.save!
 end

конец

Этот код по-прежнему вызывается из фильтра after_create, и я не вижу, чтобы он вызывался дважды, поэтому похоже, что я принял автоповтор DelayedJobs за рекурсию или что-то в этом роде.

Answer 2

Если сохранение не удалось, оно не имеет ничего общего с delayed_job (по крайней мере, этого не должно быть, если сохранение не займет больше времени, чем MAX_RUN_TIME.)

Попробуйте диагностировать проблему с помощью сохранения, не используя delayed_job.

Также взгляните на файл delayed_job.log в ваших журналах