I am looking for a feedback on how we solve situations we experience with exq: Situation 1. On start-up of the node, exq will move any entries in the “backup” queue to the main queue. The issue is when we deploy new version of the app, we have a new instance of the app running, but with the same n…

[image] tetiana: Node 1 (older node) got terminated without finishing all it’s job :astonished: Why not have it not shut down until it’s jobs finish processing, but rather just have it stop taking in new jobs?

Exq does that already. We can specify shutdown timeout and the older version of the app will allow that time to finish jobs and not pick up any new ones. Once all jobs finished it will shutdown. But if the job hasn’t finished and we reached the timeout, then it will shutdown and leave the job not fi…

Pardon the uninformed question, but why do you need the backup queue at all? What’s so radical about having to restart a node that you need a separate queue? If you give us some more context, we can come up with more ideas.

Well, that’s how exq with redis works. It uses backup queues to manage in-progress jobs. When exq performs a job, it takes the job request off the queue and places it into a “backup” queue with a node identifier that will process the job. If the job completes successfully it will remove it from the …

So why not combine node ID with a deployment or instance ID (which should change on every start-up) to achieve a unique ID? Or would that break any backwards compatibility with Resque and Sidekiq?

[image] tetiana: Implement backup queue cleaner for previous node. This is likely what I would do. Is in order processing important? If it is, then the cleaner would be insufficient. In that case you’d probably want the node name to stay the same and make your jobs idempotent or implement an…

Processing jobs during deploy

Questions & Help Questions

OvermindDL1 June 4, 2018, 10:20pm 2

Why not have it not shut down until it’s jobs finish processing, but rather just have it stop taking in new jobs?