You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wrapping a pre-check for an existing job with the same unique name when I noticed a behavior I think I understand the reason for:
If you create a job:
varkue=require('kue-scheduler');varQueue=kue.createQueue();varclient=Queue.client;//create a job instancevarjob=Queue.createJob('myjob',{'foo':'bar'}).attempts(3).priority('normal').unique('testUnique');//schedule it to run every 5 secondsQueue.every('five seconds',job,function(err,result){client.exists('q:unique:jobs',function(err,reply){if(reply===1){console.log('Immediately exists');}else{console.log('doesn\'t exist');}//wait until the job has been scheduled for the first timesetTimeout(function(){client.exists('q:unique:jobs',function(err,reply){if(reply===1){console.log('exists after scheduling');}else{console.log('doesn\'t exist');}});},6000);});});
So I noticed this, and I'm not sure how to fix it, but it does to at least be documented - as I was struggling with why if I looked in q:unique:jobs, the job would not exist until it is scheduled for the first time, but I see now that save does not get called until the first scheduled run of the job.
This creates an opportunity where you could create two jobs with the same unique constraint and it would depend on which job was scheduled last(?) which job would win in being the 'unique' job, correct?
The text was updated successfully, but these errors were encountered:
@gmcnaught This is because kue-scheduler rely much on redis working to achieve what it does in scheduling every jobs. So if you say a job to run every five seconds it will wait until five second for it to create a job.
In case of two job with the same unique constraint am planning to move on using redis data structure that fit for the work than just a stringified objects.
Hope we can work on this to improve documentation and implementing the desired feature.
I solved this on my end by looking for the existence of the data object
before creating a unique job in a wrapper of kue-scheduler, it was just an
unexpected behavior for the unique job lookup to not exist after every, but
on save.
On Mon, Feb 6, 2017 at 4:15 AM, lally elias ***@***.***> wrote:
@gmcnaught <https://github.com/gmcnaught> This is because kue-scheduler
rely much on redis working to achieve what it does in scheduling every
jobs. So if you say a job to run every five seconds it will wait until
five second for it to create a job.
In case of two job with the same unique constraint am planning to move on
using redis data structure that fit for the work than just a stringified
objects.
Hope we can work on this to improve documentation and implementing the
desired feature.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#79 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABTsf1lWW0edCdvg8Nh4vJk60nS2ybeMks5rZuS4gaJpZM4LwbfH>
.
I was wrapping a pre-check for an existing job with the same unique name when I noticed a behavior I think I understand the reason for:
If you create a job:
So I noticed this, and I'm not sure how to fix it, but it does to at least be documented - as I was struggling with why if I looked in q:unique:jobs, the job would not exist until it is scheduled for the first time, but I see now that save does not get called until the first scheduled run of the job.
This creates an opportunity where you could create two jobs with the same unique constraint and it would depend on which job was scheduled last(?) which job would win in being the 'unique' job, correct?
The text was updated successfully, but these errors were encountered: