Scheduler
Contents
Named tasks can be scheduled by XP platform to asynchronously run in the background in a cluster or a one-node environment.
Scheduled Job
A scheduled job is an object which describes how a named task must be run. It contains information about the type of scheduling, time of execution, description, etc. All job nodes are stored in a separate system.scheduler repository. See how to manipulate it with lib-scheduler API.
Properties
| Name | Type | Description |
|---|---|---|
|
name |
string |
Name of a job, unique for the entire environment |
|
description |
string |
String-format description of scheduled job |
|
descriptor |
string |
Descriptor of the task to be scheduled. Format: |
|
config |
object |
JSON object contains described task parameters |
|
calendar |
object |
|
|
user |
string |
Principal key of the task submitter. Format: |
|
enabled |
boolean |
If |
|
creator |
string |
Principal key of user that created the task |
|
modifier |
string |
Principal key of the last user that modified the task |
|
createdTime |
string |
Time of the task creation |
|
modifiedTime |
string |
Time of the last task modification |
|
lastRun |
string |
Time of the last job run |
|
lastTaskId |
string |
Task id of the last job run |
Calendar
Calendar object describes when and how the task should be run. There are two possible types: one-time and cron.
The task will be run only once. If the time value is passed at the moment of scheduling, then the task will be run immediately. Value format is ZULU time, documented in ISO 8601.
{type: 'ONE_TIME', value: '2021-01-01T10:30:00.00Z'}Should be used for repeatable tasks. UNIX cron lib format is expected. Also, a timezone must be specified to run the job at a particular time of the day.
{type: 'CRON', value: '* * * * *' // every minute
,timeZone: 'GMT+5:30'}System jobs
XP platform provides predefined system jobs, which can be enabled and overridden by user in config file. Config modification doesn’t update job nodes automatically, so make sure you’ve removed or changed old job nodes manually before any config change.
Deletes unused blobs and binaries from a blobstore.
| Make sure you have a backup of the installation available before doing a vacuum. |
init-job.vacuum.enabled=false
init-job.vacuum.cron=0 5 * * *
init-job.vacuum.descriptor=com.enonic.xp.app.system:vacuum
init-job.vacuum.description=Job to run vacuum
init-job.vacuum.user=system:suCommon vacuum process config can be found in Vacuum config file.
Deletes records from audit log repository.
| Make sure you have a backup of the installation available before running a cleanUp. |
init-job.audit-log-cleanup.enabled=false
init-job.audit-log-cleanup.cron=0 5 * * *
init-job.audit-log-cleanup.descriptor=com.enonic.xp.app.system:audit-log-cleanup
init-job.audit-log-cleanup.description=Job to clean up old audit log history
init-job.audit-log-cleanup.user=system:suCommon cleanup process config can be found in Audit config file.
ageThreshold property must be set to appropriate value, otherwise nothing will be removed. |
Distributable
XP platform guarantees that a scheduled job won’t be executed by multiple threads concurrently for the cluster environment.
| Several jobs can describe the same task descriptor, so the same code can be run by different threads simultaneously. Also, if the execution time of the task is longer than the cron period (especially important for long-term jobs) then a new task can be started before the previous is finished. |
A scheduled job can be executed by any cluster node supporting an application, which contains the described task. See task for further explanation.
