There is a race-condition in JesqueSchedulerService#acquireJobs which seems to be caused if the scheduler threads have different latencys to the redis instance.
So 2 threads are getting the same job from Trigger.TRIGGER_NEXTFIRE_INDEX.
Since we only call watch after that, if one server is so fast that it called watch and executed the transaction, the other thread may not have called watch yet and so doesn't see that the fast thread already aquired and executed the job. The slow thread then calls watch and executes his transaction, causing the scheduled job to be enqueued a second time.
This patch fixes this issue by comparing jobData.score and trigger.nextFireTime.millis after we've called watch.
The fast thread will have updated the trigger.nextFireTime so that it's now different from the jobData.score that we've read before calling watch.
There is a race-condition in
JesqueSchedulerService#acquireJobswhich seems to be caused if the scheduler threads have different latencys to the redis instance.So 2 threads are getting the same job from
Trigger.TRIGGER_NEXTFIRE_INDEX. Since we only call watch after that, if one server is so fast that it called watch and executed the transaction, the other thread may not have called watch yet and so doesn't see that the fast thread already aquired and executed the job. The slow thread then calls watch and executes his transaction, causing the scheduled job to be enqueued a second time.This patch fixes this issue by comparing
jobData.scoreandtrigger.nextFireTime.millisafter we've called watch. The fast thread will have updated thetrigger.nextFireTimeso that it's now different from thejobData.scorethat we've read before calling watch.Fixes #29