Before deciding to use a queue package I was researching the limits of Meteor.setTimeout and how far into the future it will work. One of my use-cases is to allow the user to schedule events many months, even years, into the future.
Upon reading the docs on how this package varies from msavin:SteveJobs, it mentions using setTimeout to process the next job versus setInterval to query for jobs.
According to this, this, and this, the maximum length a setTimeout can be called in node.js mirrors the same maximum that is used for browsers which is 2147483647 ms which is 24.8 days. So... anything scheduled farther out than that may have a problem with this package's implementation.
It sounds like you'd either need an interval-type check or do some daisy-chaining of setTimeout to circumvent the limit which seems to be the approach that is taken most.
Thanks @evolross, and well spotted! I've released v1.0.9 which caps the setTimeout to 24 hours. If no jobs are scheduled then a new timeout will be created.
Before deciding to use a queue package I was researching the limits of
Meteor.setTimeout
and how far into the future it will work. One of my use-cases is to allow the user to schedule events many months, even years, into the future.Upon reading the docs on how this package varies from msavin:SteveJobs, it mentions using
setTimeout
to process the next job versussetInterval
to query for jobs.According to this, this, and this, the maximum length a
setTimeout
can be called in node.js mirrors the same maximum that is used for browsers which is 2147483647 ms which is 24.8 days. So... anything scheduled farther out than that may have a problem with this package's implementation.It sounds like you'd either need an interval-type check or do some daisy-chaining of
setTimeout
to circumvent the limit which seems to be the approach that is taken most.