gresrun
commented
7 years ago TL;DR: Jesque's scheduled jobs are simpler and more reliable, using Redis ZSETs instead of a dedicated scheduler task.
From the conversation in #69:
After digging a bit more into the resque-scheduler implementation, it does appear that the delayed jobs feature is implemented quite differently in Jesque.
Basically, resque-scheduler clients add delayed jobs by appending job information into three data structures (a list, a set and and a zset) and then has at least one dedicated scheduler that enqueues those delayed jobs into normal queues (Redis lists) at the desired time and then workers pull off that job. This is quite different from Jesque's approach, in which clients immediately enqueue a job into a special delayed queue (a Redis zset) and workers pull off jobs from that delayed queue whose time has come to pass.
The resque-scheduler approach is quite a bit more complicated, requiring four Redis keys (two lists, a set and a zset) to enqueue a delayed job, and requires a scheduler must be running at the time the delayed job is ready in order to enqueue it into a regular queue. While I was not the original author of the delayed job feature (@anismiles was the initial contributor), I feel the feature's incompatibility with resque-scheduler is acceptable given the benefits of simplicity and reliability of Jesque's current implementation of delayed queues.
I would like to learn the reasons for why jesque is not compatible with resque-scheduler regarding delayed and recurring jobs. As far as I understand, resque-scheduler basically enqueues delayed jobs as normal jobs once their time is due. I think this is a good concept. Why did you diverge from this when implementing delayed job?
We might consider implementing a resque-scheduler compatible version of delayed and recurring jobs on top of Jesque, so I am curious about your decision.