Magnolia 5.5 reached end of life on November 15, 2019. This branch is no longer supported, see End-of-life policy.
The Magnolia Scheduler module allows you to schedule commands to run at regularly scheduled times and is powered by the Quartz Engine.
<dependency> <groupId>info.magnolia</groupId> <artifactId>magnolia-module-scheduler</artifactId> <version>2.3.6</version> </dependency>
The Scheduler module can be used to execute any configured command at regular intervals. For example, it can:
The Scheduler module is used to execute commands that are typically configured in other modules. See Commands for more.
Scheduled tasks are configured in modules/scheduler/config/jobs
.
Example: demo
job that activates the /news
page hourly.
Node name | Value |
---|---|
modules | |
scheduler | |
config | |
jobs | |
demo | |
params | |
path | /news |
repository | website |
catalog | website |
command | activate |
cron | 0 0 * * * * |
description | activate each hour the page news.html |
enabled | false |
cleanTempFiles | |
checkLicense | |
generatePlanetData | |
collectPlanetStatistics | |
removeCategories | |
generateCategories |
Properties:
jobs | required Jobs node. |
| required Name of the job. |
| optional Parameters node. |
| required/optional Parameters passed to the command. Depends on the command. For example, the |
| required Name of the catalog where the command resides |
| required Name of the command |
| required CRON expression that sets the scheduled execution time. For example |
| optional Description of the job |
| optional, default is Enables and disables the job. |
| optional, default is Defines whether the same job can be running concurrently. |
The Synchronization, Backup and RSS Aggregator modules use the Scheduler module for scheduling their execution.
In a clustered configuration one or more workspaces is stored in a shared, clustered storage. See Clustering for more. Cluster nodes (Magnolia instances) access the clustered workspace rather than their own workspaces. This can lead to a situation where multiple scheduled jobs attempt to access the same content simultaneously and a lockup occurs. To avoid this situation, identify the cluster nodes and run the job on only one node.
magnolia.clusterid
property in the magnolia.properties
file of the cluster node. The file is in the /<CATALINA_HOME>/webapps/<contextPath>/WEB-INF/config/default
folder. The property value can be a literal cluster name such as public123
(magnolia.clusterid=public123
) or a variable such as ${servername
}./modules
/scheduler
/jobs
and edit the job configuration.Under the params
node, add a clusterId
property and set the value to match the magnolia.clusterId
of the cluster node where you want to run the job.
Node name | Value |
---|---|
scheduler | |
config | |
jobs | |
demo | |
params | |
clusterID | cluster1 |
path | /news |
repository | website |
enabled | false |
.... | .... |
Job configurations are stored in the config
workspace. If you want to run a particular job on all cluster nodes you would have to cluster the config
workspace so that all instances can read the configuration or create the same job configuration on all cluster nodes. This can be time consuming. As a workaround, configure the job once on a clustered instance without the clusterId
property. This has the effect that the job will run on all cluster nodes.