getProductQuantityoperation and set an event (e.g., send an email) if the quantity goes down to some level.
Task scheduling functionality is provided by the Data Service Tasks feature in the WSO2 feature repository. The associated identifier is
The scheduled tasks configuration is a generic configuration, which is used by any component that requires scheduled tasks functionality. The scheduled tasks support many modes of operations and fully supports load balancing and fail-over of tasks. The tasks configuration file can be found in the
<PRODUCT_HOME>/repository/conf/etc/tasks-config.xml file. The default configuration is shown below:
The default values in the
tasks-config.xml file allow the user to do minimal changes when running in both standalone and clustered modes.
The task server mode is set to
AUTO by default, which automatically detects if clustering is enabled in the server and by default switches to clustered mode of scheduled tasks.
Task Handling Modes
There are four task handling modes available for all WSO2 Carbon servers.
- AUTO - This is the default task handling mode. This setting detects if clustering is enabled in the server and automatically switches to
CLUSTEREDtask handling mode.
- STANDALONE - This mode is used when the Carbon server is used as a single installation. That is, tasks will be managed locally within the server.
- CLUSTERED - This mode is used when a cluster of Carbon servers are put together. With this setting, if one of the servers in the cluster fail, the tasks will be rescheduled in one of the remaining server nodes. This requires Axis2 clustering to work.
- REMOTE - This mode is used when all tasks should be triggered using an independent task handling server. That is, all carbon servers using such an external task handling server should be running on
REMOTEmode, while the task handling server can be running on
The task server count is set to
two by default. This setting denotes the number of nodes in the task server cluster in the clustered mode that must be running before scheduled tasks can run, so that the scheduled tasks will be shared among the given number of nodes at startup.
For example, assume 10 tasks were saved and scheduled earlier, and for some reason later the cluster was brought down. As individual servers come back online, we do not want the first server to schedule all the tasks. Rather, we want at least two servers to come back up and share the 10 tasks.
The task clustering is based on a peer-to-peer communication mechanism. When carrying out the fail-over scenarios, it can rarely result in split-brain scenarios, where the same task can be scheduled without knowing it is already scheduled somewhere else. So the task implementors should make their best effort to make the task functionality idempotent, or come up with a mechanism to detect if the current task is already running elsewhere.