| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Notably, it is now possible to add a randomized spread factor to the check
interval.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Requested feature for many modules, notably MAM and file sharing.
|
|
|
|
| |
Use of datetime was removed in 6ac5ad578565
|
|
|
|
|
| |
This ensures that all interactions with storage happen inside an async
thread, allowing async waiting to be performed in storage drivers.
|
|
|
|
|
|
|
| |
Maybe it is better to run daily and weekly tasks 'now' on the theory
that people set these things up during times that are appropriate for
maintenance already, so the same time next day or next week might be
fine for periodic cleanup.
|
| |
|
|
|
|
|
|
|
| |
The type checks, they do nothing!
Observed: Tasks that were supposed to run weekly or daily were running
each hour.
|
|
|
|
|
|
|
|
|
| |
If the timer activates a bit early then a task might be just a few
seconds short of being allowed to run. This would run such a task rather
than wait another hour.
The value 0.5% chosen so that a weekly task does not run an entire hour
earlier than last time.
|
|
|
|
|
| |
This makes it easier to reschedule or otherwise manipulate the timer
from e.g. the shell, which is handy for debugging.
|
| |
|
|
|
|
|
| |
Makes it more generic so new periods (e.g. weekly etc) can be added
easily.
|
| |
|
|
|
|
|
|
| |
Eventually the goal is to have daily tasks run while there is little
activity, but that will vary with the server and the usage patterns of
its users. This is a start anyway.
|
|
A number of modules now have periodic tasks that need to run, e.g. for
cleaning out old messages or files. This has highlighted a need for
coordinating and optimizing scheduling of such tasks.
|