Неправильная сериализация обработчика заданий при запуске delayed_job в производстве с Thin или Unicorn

Question

Я недавно добавил delayed_job в свое приложение Rails 3.1.3.В разработке все нормально.Я даже поставил свой DJ-релиз на тот же VPS, что и мое производственное приложение, используя тот же сервер производственных приложений (Thin), и все было хорошо.Однако, как только я перешел на работу, весь ад развалился: ни одно из заданий не было правильно введено в таблицу заданий, и я начал видеть следующее в журналах для всех обработанных заданий:

2012-02-18T14:41:51-0600: [Worker(delayed_job host:hope pid:12965)] 
NilClass# completed after 0.0151 
2012-02-18T14:41:51-0600: [Worker(delayed_job host:hope pid:12965)] 1 
jobs processed at 15.9666 j/s, 0 failed ... 

NilClass инет имени метода?Конечно, не правильно.Поэтому я посмотрел на сериализованный обработчик задания в БД и увидел:

"--- !ruby/object:Delayed::PerformableMethod\nattributes:\n  id: 13\n 
event_id: 26\n  name: memememe\n  api_key: !!null \n" 

Нет указания на имя класса или метода.И когда я загружаю YAML в объект и вызываю #object в результирующем PerformableMethod, я получаю ноль.Затем я запустил консоль в сломанном производственном приложении и отложил ту же работу.На этот раз обработчик выглядел так:

"--- !ruby/object:Delayed::PerformableMethod\nobject: !ruby/ 
ActiveRecord:Domain\n  attributes:\n    id: 13\n    event_id: 26\n 
name: memememe\n    api_key: !!null \nmethod_name: :create_a\nargs: [] 
\n" 

И, конечно же, эта работа работает нормально.Озадаченный, я вспомнил, что читал что-то о ди-джеях, которые не играют с Thin.Итак, я попробовал Unicorn и мне было грустно видеть тот же результат.Несколько часов спустя, и я думаю, что это как-то связано с тем, как сервер приложений загружает библиотеки YAML Psych, Syck и DJ с ними.Однако я не могу точно определить, что не так.

Обратите внимание, что у меня запущено официальное delayed_job 3.0.1, но я попытался перейти на основную ветку и даже попытался перейти на 2.1.4.Вот некоторые заметные различия между моей сценической и производственной установками:

• На этапе я запускаю 1 тонкий сервер на TCP-порту - нет веб-прокси впереди
• На производстве я запускаю 2+ Тонкие серверы и прокси к ним с Nginx.Они общаются через сокет UNIX
• Когда я попробовал Unicorn, это был 1 сервер приложений, к которому Nginx проксировал через сокет UNIX

Может ли веб-прокси / Nginx иметь с этим какое-то отношение??Пожалуйста, любая оценка очень ценится.Я потратил много времени на интеграцию delayed_job и не хотел бы откладывать работу или, что еще хуже, бросать ее.Спасибо за чтение.

Answer 1

Я исправил это, не используя #delay.Вместо этого я заменил весь мой код "model.delay.method" на пользовательские задания.Это работает как обаяние и в конечном итоге является более гибким.Это исправление прекрасно работает с Thin.Я не тестировал с Единорогом.

Answer 2

У меня похожая проблема с rails 3.0.10 и dj 2.1.4, это, скорее всего, другая библиотека yaml, загружаемая при запуске из консоли против сервера приложений; худой, единорог, нгинкс. Я поделюсь любым решением, которое мне придет

Хорошо, поэтому удаление этих строк из config / boot.rb устранило эту проблему для меня.

require 'yaml'
YAML::ENGINE.yamler = 'syck'

Это было помещено туда, чтобы исправить ошибку синтаксического анализа YAML, заставив YAML использовать 'syck'. Удаление этого потребовало от меня исправить основные проблемы с файлами .yml. Подробнее об этом здесь

Теперь мои обработчики отложенных заданий совпадают между созданными через сервер (единорог в моем случае) и консолью. И мой сервер, и работники с задержкой на работу запускаются в связке

Unicorn

cd #{rails_root} && bundle exec unicorn_rails -c #{rails_root}/config/unicorn.rb -E #{rails_env} -D"

DJ

export LANG=en_US.utf8; export GEM_HOME=/data/reception/current/vendor/bundle/ruby/1.9.1; cd #{rail

s_root}; /usr/bin/ruby1.9.1 / data / receive / current / script / delayed_job начать подготовку