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
{{ message }}
This repository has been archived by the owner on Feb 5, 2020. It is now read-only.
The scheduler service shows some inconsistent / unexpected behavior with scheduling. Perhaps this is simply my misunderstanding, but from what I'm seeing:
the minimum interval (set globally in config.'scheduler.interval' with a default of 10s) disallows any scheduled services with an interval less than 10s because the global timeout only runs on this schedule
the timeoutHandler checks if the current timestamp is greater than the lastRun + the serviceInterval. So, if a job last ran 10 seconds ago and is scheduled for 10 second intervals, it may not run until the next iteration.
the lastRun value for each service is only set after the service completes. So, if a job is scheduled to run every 10 seconds, and takes 200ms to run, it would only run every 20 seconds.
Proposed changes:
Set the global timeout interval for the timeoutHandler to the greatest common factor (so that a 10s interval doesn't artificially delay a 15s interval)
Change the time check to a "greater than or equal to" check
Set the lastRun value to the timestamp when the service starts. (Note: we do not run the risk of concurrent executions because of the check on the boolean flag of running that is maintained for each service.)
The text was updated successfully, but these errors were encountered:
It may be worth looking into implementing this with a third party library like https://github.com/agenda/agenda that would allow for persistence and multi-node support (e.g., only running a job on one node in a cluster by using MongoDB for locking support).
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The
scheduler
service shows some inconsistent / unexpected behavior with scheduling. Perhaps this is simply my misunderstanding, but from what I'm seeing:timeoutHandler
checks if the current timestamp is greater than the lastRun + the serviceInterval. So, if a job last ran 10 seconds ago and is scheduled for 10 second intervals, it may not run until the next iteration.lastRun
value for each service is only set after the service completes. So, if a job is scheduled to run every 10 seconds, and takes 200ms to run, it would only run every 20 seconds.Proposed changes:
timeoutHandler
to the greatest common factor (so that a 10s interval doesn't artificially delay a 15s interval)lastRun
value to the timestamp when the service starts. (Note: we do not run the risk of concurrent executions because of the check on the boolean flag ofrunning
that is maintained for each service.)The text was updated successfully, but these errors were encountered: