Восстановление из Resque :: TermException или SIGTERM на Heroku

Question

Когда мы перезапускаем или развертываем, мы получаем несколько заданий Resque в неудавшейся очереди с Resque::TermException (SIGTERM) или Resque::DirtyExit.

Мы используем в нашей PROCFILE новый TERM_CHILD=1 RESQUE_TERM_TIMEOUT=10 поэтому наш работник линия выглядит следующим образом:

worker: TERM_CHILD=1 RESQUE_TERM_TIMEOUT=10 bundle exec rake environment resque:work QUEUE=critical,high,low 

Мы также используем resque-retry, который я думал, что мощь автоматического повтора этих двух исключений? Но, похоже, этого не происходит.

Так что я думаю, два вопроса:

1. Мы могли бы вручную спасти от Resque::TermException в каждой работе, и использовать это, чтобы перенести работу. Но есть ли чистый способ сделать это для всех рабочих мест? Даже патч обезьяны.
2. Не следует повторно повторять попытку повторного повтора? Можете ли вы подумать о какой-либо причине, почему это не так?

Спасибо!

Редактировать: Получение всех рабочих мест за менее чем 10 секунд кажется необоснованным по шкале. Кажется, должен быть способ автоматически переупорядочить эти задания при выполнении исключения Resque :: DirtyExit.

Answer 1

Выполнены ли ваши рескские задания более 10 секунд? Если задания завершаются в течение 10 секунд после отправки начального SIGTERM, вы должны быть в порядке. Попытайтесь разбить задания на более мелкие куски, которые заканчиваются быстрее.

Кроме того, вы можете иметь ваш рабочий повторно Епдиеие работу делать что-то вроде этого: https://gist.github.com/mrrooijen/3719427

Answer 2

1. Мы могли бы вручную спасти от Resque :: TermException в каждой работе, и использовать это, чтобы перенести работу , Но есть ли чистый способ сделать это для всех заданий? Даже патч обезьяны.

Resque::DirtyExit возбуждается исключение, когда работа будет убит с SIGTERM сигналом. У задания нет возможности поймать исключение, так как вы можете read here.

2. Не следует повторно повторять попытку повторного повтора? Можете ли вы подумать о какой-либо причине, почему это не так?

Не понимаю, почему это не должно быть, работает ли планировщик? Если не rake resque:scheduler.

Я написал подробный блог вокруг некоторых из проблем, которые я имел в последнее время с Resque::DirtyExit, может быть полезно =>Understanding the Resque internals – Resque::DirtyExit unveiled

Answer 3

Я также боролся с этим на некоторое время, не найдя надежное решение.

Одно из немногих решений, которые я нашел, запускает задачу рейка по расписанию (задание cron каждые 1 минуту), которое ищет неудачные задания с помощью Resque :: DirtyExit, повторяет эти конкретные задания и удаляет эти задания из отказа очередь.

Вот образец передней задачи https://gist.github.com/CharlesP/1818418754aec03403b3

Это решение явно неоптимальным, но на сегодняшний день это лучшее решение, которое я нашел, чтобы повторить эти задания.

Answer 4

Я столкнулся с этой проблемой. Оказывается, Heroku отправляет сигнал SIGTERM не только родительскому процессу, но и всем разветвленным процессам. Это не та логика, которую ожидает Resque, которая вызывает пропущение RESQUE_PRE_SHUTDOWN_TIMEOUT, заставляя выполнение заданий без каких-либо попыток завершить работу.

Heroku дает работникам 30-е годы изящно завершить работу после выпуска SIGTERM. В большинстве случаев это достаточно времени, чтобы закончить работу с некоторым оставшимся временем буфера, чтобы выполнить задание Resque, если задание не удалось завершить. Тем не менее, за все это время, которое необходимо использовать, вам необходимо установить RESQUE_PRE_SHUTDOWN_TIMEOUT и RESQUE_TERM_TIMEOUT env vars, а также патч Resque, чтобы правильно ответить на SIGTERM, отправляемый на разветвленные процессы.

Вот драгоценный камень, который исправляет Resque и объясняет этот вопрос более подробно:

https://github.com/iloveitaly/resque-heroku-signals