Scheduling Tasks
Task scheduling is used to invoke an operation periodically or only a specified number of times. The scheduling functionality is useful when a specific data service operation scheduled to execute is associated with an event trigger. When such a scheduled task is run, the event can be automatically fired by evaluating the event trigger criteria. For example, you can schedule a task on the getProductQuantity
operation 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 org.wso2.carbon.dataservices.task.feature.group
.
Tasks Configuration
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:
<tasks-configuration xmlns:svns="http://org.wso2.securevault/configuration"> <!-- The currently running server mode; possible values are:- STANDALONE, CLUSTERED, REMOTE, AUTO. In AUTO mode, the server startup checks whether clustering is enabled in the system, if so, CLUSTERED mode will be used, or else, the the server mode will be STANDALONE. --> <taskServerMode>AUTO</taskServerMode> <!-- To be used in CLUSTERED mode to notify how many servers are there in the task server cluster, the servers wait till this amount of servers are activated before the tasks are scheduled --> <taskServerCount>2</taskServerCount> <!-- The address to which the remote task server should dispatch the trigger messages to, usually this would be an endpoint to a load balancer --> <taskClientDispatchAddress>https://localhost:9448</taskClientDispatchAddress> <!-- The address of the remote task server --> <remoteServerAddress>https://localhost:9443</remoteServerAddress> <!-- The username to authenticate to the remote task server --> <remoteServerUsername>admin</remoteServerUsername> <!-- The password to authenticate to the remote task server --> <remoteServerPassword>admin</remoteServerPassword> <!-- Below contain a sample to be used when using with secure vault --> <!--remoteServerPassword svns:secretAlias="remote.task.server.password"></remoteServerPassword--> </tasks-configuration>
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
CLUSTERED
task 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
REMOTE
mode, while the task handling server can be running onAUTO
,STANDALONE
orCLUSTERED
mode.
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.