Console, cronjobs and background work #

This page is for engineers who design work that should not run inside a web request: imports, cleanups, mail, indexing, large content operations. Exponential has three mechanisms for it, plus the console that runs them all.

Contents #

1. The console
2. Cronjob parts
3. Content jobs
4. The job queue: expqueue
5. Which one to use
6. Rules

The console #

bin/php/console is one entry point for every command (installations usually add a ./console shortcut in the root). It discovers commands at run time:

The code of a kernel command is an Exponential\Runnable\Command class in kernel/private/classes/commands/; the file in bin/php/ is a one-line entry point. Scripts boot through eZScript, not ezpKernelWeb. Reference: Exponential Console; for authors, Console commands.

php bin/php/console list              # every command
php bin/php/console list cron         # cronjob parts
php bin/php/console help exp:preload  # the help of one command

Cronjob parts #

runcronjobs.php runs the parts configured in settings/cronjob.ini: [CronjobSettings] Scripts[] for the default part and [CronjobPart-<name>] Scripts[] for named parts such as frequent and infrequent. The code of a part is an Exponential\Runnable\CronjobPart class in kernel/private/classes/cronjobs/.

php runcronjobs.php frequent

The frequent group matters on every installation: it contains, among others, the audit part that indexes, delivers, evaluates alert rules and rotates the audit trail (The audit trail). Cronjobs can be listed, run and paused from the console and the administration (Cronjobs console, Cronjob pause).

Content jobs #

Large removes, copies, moves, package installs and audit exports run as content jobs: the request queues the job and returns, and the work proceeds in batches in the background (Content jobs, Content jobs feature page).

The job queue: expqueue #

expqueue is a database-backed job queue for extensions, required by composer.json from 6.0.15 on and inactive until activated. Producers queue a job with one call; workers run it on the command line, from cron or as a systemd service, never inside a web request. It offers priority classes, retries with backoff, a dead letter, idempotency keys and leases with a reaper (expqueue: the job queue, Queues with expqueue).

Which one to use #

Rules #

• A cronjob part must be safe to run twice and to be interrupted.
• A command must keep its --help text and exit codes stable, because scripts and cron depend on them, and should offer --dry-run when it changes data.
• Shared logic goes into a service class that views, commands and parts all call (Background work patterns).
• Long-running workers see a class change only after they restart, like Velocity's workers.

Related pages #

• Cronjobs
• CLI scripts
• Commands, cronjob parts and module views as classes
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.