Scheduled Tasks Proposal
Introduction
This proposal is meant both to provide a replacement for the moodle cron job, and provide a means to schedule once off tasks to be run outside of the user's request lifecycle.
Terminology
- *Subtask* an individual piece of cron processing that should be run (equivalent to forum_cron now, or maybe even smaller)
- *Moodle cron instance* a cron.php process
Rationale
The moodle cronjob currently delegates all scheduling to each subtask that is run - for example, the forum cron is responsible for checking when it last run, and making decisions about whether or not it should be run again. This sort of decision process should be centralised, and individual cron subtasks should be called by the central controller.
Additionally, there is not any central locking of subtasks. At the moment, some subtasks that expect that they might take a long time to run implement their own locking (for example statistics), but it's not centralised. Each moodle cron instance runs to completion, no matter how long it takes, and it processes tasks in the order that they're programmed, regardless of if there are any other moodle cron instances running, that might be processing sub tasks in parallel
Finally, we need to be able to run non-related tasks in parallel so that the entire moodle queue isn't held up by single long running jobs.
Goals
- Admin screen to move around scheduling.
- ...
Unresolved issues
- Do we need to allow for scheduling different subtasks on different servers?
- We need to find a way to separate subtasks by some logic so that subtasks that write to the same areas of the database never run at the same time. We could do this by getting each cron job to say what areas of Moodle they write to, but this is problematic.
- We also have to deal with the order of some subtasks - we could maybe do this by introducing dependencies
- When the first cron in a long time is running, we should lock the entire cron and let it run to completeness, because the order is really important then.
