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, tasks are scheduled in the analyzer nodes according to the round robin algorithm. 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 on AUTO, STANDALONE or CLUSTERED 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.