5 ms·
Mike, I'm curious if you think Sidekiq suffers from a similar issue on Heroku, and what the solutions - ideas or already implemented - look like?
by neodude 12y ago
Mike, I'm curious if you think Sidekiq suffers from a similar issue on Heroku, and what the solutions - ideas or already implemented - look like?
- ejlangev 12y ago+1 on that question, I'd be very interested in that as well. My guess would be that since Sidekiq is thread-based rather than process-based it wouldn't have to deal with the issue of all processes receiving the signal at the same time.
- mperham 12y agoAFAIK this problem is endemic to any job processing system where jobs can take more than N seconds to process. What Heroku does: * Heroku sends the TERM signal. * The process has 10 seconds to exit itself. * After 10 seconds, the KILL signal is sent to terminate the process without notice. Sidekiq does this: * Upon TERM, the job fetcher thread is halted immediately so no more work is started. * Sidekiq waits 8 seconds for any busy Processors to finish their job. * After 8 seconds, Sidekiq::Shutdown is raised on each busy Processor. The corresponding jobs are pushed back to Redis so they can be restarted later. This must be done within 2 seconds. * Sidekiq exits or is KILLed.