Spike: job manager: breeejs out, node-cron in #308
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The job manager has one fatal flaw: it's not possible to schedule a recurring job that runs in the main thread; only in a worker thread.
In Ghost we've hacked around this by scheduling a worker job, then emitting an event back to the main thread to trigger a job to execute. This works, but it's essentially a really convoluted and expensive
setTimeout()...why not just use asetTimeout()?This spike rips out breejs entirely, and uses
node-cronto handle the scheduling bits. This way we can just pass a function to addJob() and it will run on the provided schedule in the main thread, without having to spawn a worker.This does mean we no longer support running jobs in worker threads at all, which we'll probably need to solve. There's nothing stopping us from launching a worker within the function we pass to node-cron, or even pass it to a pool of workers to handle.