Open joncursi opened 7 years ago
This produces the functionality I'm looking for...
later.setInterval(
Meteor.bindEnvironment(() => {
new Job(jobCollection, 'REFRESH_COIN_COUNTS', {}).save();
}),
later.parse.text('every 1 seconds'),
);
jobCollection.processJobs('REFRESH_COIN_COUNTS', {
pollInterval: 500,
}, (job, callback) => {
console.log(new Date());
job.done();
callback();
});
... but I'm not sure if this is the correct way to do it, especially since it seems schedule
on repeat
is trying to achieve the same thing.
If you want very low latency, I recommend using the approach outlined here (instead of polling):
https://github.com/vsivsi/meteor-job-collection#qtrigger---anywhere
That will take care of the "worker" side. On the server side, you should also reduce the time of the "promotion" interval:
https://github.com/vsivsi/meteor-job-collection#jcpromotemilliseconds---server-only
That defaults to 15s and is the reason in the OP that you were only seeing jobs run at that rate.
The final thing account for is that when using repeat
, the next repeat of a job will only run after the previous run is done. Repeating jobs will never overlap.
I don't understand the usage of
schedule
withinrepeat
. Consider the following code:job
worker
My expectation in writing the above code is that every second, the worker will log to the console since it's polling for new jobs every 500ms, and I'm saying that the job should schedule to run every second.
Instead, this is what I'm getting in console (two logs, every ~15 seconds):
A) I'm so confused on the above.
B) After reading this, it seems like an alternative to
schedule
on an existing job is to schedule NEW jobs every second (physically insert a new document into the jobs collection in MongoDB). I like that approach, but the only way I can figure out how to do this is wrapping my job inMeteor.setInterval
, but that feels sloppy. Surely there's a better way?