In MuleSoft projects, when there is a business requirement to self trigger a process, it can be realized in two unique ways:
- Without human intervention Or
- Without external system invocation
This is based on two further basic approaches:
- Schedule based (cron)
- Time interval based
MuleSoft Scheduler
MuleSoft provides the following scheduling mechanisms:
- Fixed Frequency schedule: Can control the frequency with units of milliseconds, seconds, minutes, hours and days
- Cron Expression based schedule: Cron only supports from seconds upwards i.e. only frequency with units of seconds, minutes, hours and days.
If you ever wondered how the scheduler behaves in deployments to multiple workers on CloudHub, this article explains.
Scenario 1: One Worker and Single Scheduler
| Mode | Behaviour |
| Running in normal mode | The scheduler runs as per schedule on that worker node. |
| Worker crashes | The Application restarts and the Scheduler run as expected after a successful application start. |
Scenario 2: More than One Worker and Single Scheduler
| Mode | Behaviour |
| Running in normal mode | The scheduler runs in only one worker node (primary node). The other nodes as a fail-safe. |
| Worker crashes | If the worker node in which the scheduler runs crashes, another available worker node runs the scheduler. |
Scenario 3: One Worker and Multiple Schedulers
| Mode | Behaviour |
| Running in normal mode | All the Schedulers run as per their respective schedule on that single worker node. |
| Worker crashes | The Application restarts and the Scheduler run as expected after a successful application start. |
Scenario 4: More than One Worker and Multiple Schedulers
| Mode | Behaviour |
| Running in normal mode | All the schedulers run in only one worker node (primary node) The schedules run only on a single worker. There is no situation where schedules are divided across multiple workers. |
| Worker crashes | If the worker node in which the schedulers are running crashes, another available worker node takes the responsibility and executes all the schedulers as per their schedule. |
Can the Scheduler run when previously scheduled flow is still running?
No. If the previous trigger flow is still executing, the scheduler will not trigger another executing of the flow.
Example:
Consider a design scenario where a scheduler is used to load data from a database to a local object store (non-persistent object store). The behaviour in the multi-worker scenario is worth paying attention to from a design perspective. The data will only be loaded into one of the worker object store and not all other worker object stores.
When using an object store without persistence, the object store is local to the worker and not global across workers.
In this particular use case, the scheduler will only run on one worker, i.e. will only load the data to the local object store in one worker. Another worker local object store will not be loaded by the scheduler, as it will not run in other workers.
End note:
With this short article, we have tried to cover the way Mule 4 Scheduler works in Multi-Worker Environments and provided the outlook across varied and diverse scenarios.
If you found this article insightful, you may be interested in our article on why automated code quality should be the number one priority for Mulesoft applications?
To read the article follow the below link:
