Magnolia 5.4 reached end of life on November 15, 2018. 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.2.3</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
demo job that activates the
/news page hourly.
|0 0 * * * *|
|activate each hour the page news.html|
Name of the job.
Parameters passed to the command. Depends on the command. For example, the
Name of the catalog where the command resides
Name of the command
CRON expression that sets the scheduled execution time. For example
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.clusteridproperty in the
magnolia.propertiesfile of the cluster node. The file is in the
/<CATALINA_HOME>/webapps/<contextPath>/WEB-INF/config/defaultfolder. The property value can be a literal cluster name such as
magnolia.clusterid=public123) or a variable such as
jobsand edit the job configuration.
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.
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.
Would you please clarify the following inconsistency.
The documentation uses the "enabled" property for a given job, but the jobs/demo sample above uses an "active" property which is not explained.
Also, the cron value used in the demo node (0 0 * * * *) is not valid according to cronmaker.com
Hello Fadi, thanks for pointing out those issues.
activehas actually been deprecated and replaced with
enabled. It should still work anyway.
*for both day of week and day of month. Will check if this is actually still the case.
Hope this helps,
Thank you Frederico, both comments help a lot, especially the Quarts scheduler expression difference.
I was having trouble getting a scheduler to work so was basically checking that could be breaking it (turned out to be a different issue later), but thought I'd point these out when I came across them.
Considering using the scheduler module to trigger a command periodically.
I'm wondering which user account the command would run as. I need to make sure permissions are appropriately configured for this account.
Would you please let me know?
Christoph Meier, would you please let me know if you have feedback on the above question? (which Magnolia user does the scheduled command run as?)
The command will be run inside a system context will full permissions. See this code. So in the end you do not need to worry about permissions on a specific account.