This gem patches resque to be compatible with the Heroku platform. Specifically it modifies the UNIX signaling logic to be compatible with the Heroku worker shutdown process.
Read this GitHub comment for more context & details.
The version of this gem corresponds to the version of Resque that it is compatible with.
Add this line to your application's Gemfile:
gem 'resque-heroku-signals'Since this gem monkeypatches the Heroku worker the gemspec is locked to a x.x.x version of Resque to ensure the monkeypatched logic is compatible with any changes in the original Resque logic. Issue a PR if this is not compatible with the version of resque you are using.
Heroku sends a TERM signal to a process before hard killing it. If your job communicates with slow external APIs, you may want to make sure you have enough time to receive and handle the response from the external system before executing the API requests.
Ideally, using an idempotency key with each external API request is the best way to ensure that a given API request only runs. However, depending on your application logic this may not be practical and knowing if a process will be terminated in less than 30s by Heroku is a useful tool.
Use Resque.heroku_will_terminate? to determine if Heroku will terminate your process within 30s.
worker: env QUEUE=* TERM_CHILD=1 INTERVAL=0.1 RESQUE_PRE_SHUTDOWN_TIMEOUT=20 RESQUE_TERM_TIMEOUT=8 bundle exec rake resque:work
RESQUE_PRE_SHUTDOWN_TIMEOUTtime a job has to finish up before theTermExceptionexception is raisedRESQUE_TERM_TIMEOUTtime the job has to cleanup & save state- Total shutdown time should be less than 30s. This is the time Heroku gives you to cleanup before a
SIGKILLis issued INTERVALseconds to wait between jobs
Also, make you don't buffer logs: important log messages could fail to push to stdout during the worker shutdown process:
$stdout.sync = trueThe gem is available as open source under the terms of the MIT License.