>It's because the shutdown semantics in the default build of Resque don't work well in Heroku.
The shutdown semantics of DelayedJob don't work all that well either, unless you're running very short jobs - when your app restarts (is deployed to, manually restarted, has an addon added, etc), they send a SIGQUIT to all your processes, followed 5-10 seconds later by a SIGKILL. DelayedJob takes SIGQUIT to mean 'quit when you are done with your current job' and SIGKILL just terminates the process; more importantly, DJ does not propagate that SIGQUIT in any way accessible by your application code. This means that, if you have jobs dont finish before the kill signal, the worker will terminate without unlocking the job, and they will stay locked until the configured max_job_length has elapsed and some other worker picks it up. I have a monkey patch (no interest in the related pull-request) that allows you to config DJ to propagate the quit signal exception into your application code, to be handled (so you can clean up locks and terminate before the SIGKILL arrives), but it's specific to the 2.1.4 gem (should be easy to adapt): https://gist.github.com/1451524 -- You received this message because you are subscribed to the Google Groups "Heroku" group. To view this discussion on the web visit https://groups.google.com/d/msg/heroku/-/aKErYIdyz_YJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
