Scheduled Tasks

The Scheduled Tasks feature can be used to invoke a particular operation periodically. The scheduling functionality is useful when a specific data service operation, which is 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 even-trigger criteria. For example, we can scheduled a task on 'getProductQuantity' operation and set an event (e.g. sending an email) if the quantity goes down to some level.

Task scheduling functionality is provided by the following feature in the WSO2 feature repository:

Name : Data Service Tasks Feature
Identifier : org.wso2.carbon.dataservices.task.feature.group

The "Scheduled Task" feature facilitates task coordination as well, which is useful in a clustered environment. This is how you can enable the task coordination functionality:

By default, the coordination functionality is disable in tasks. It can be enabled using the configuration file "coordination-client-config.xml" located in <CARBON_HOME>/repository/conf/advanced directory. Set "<CoordinationClientConfiguration enabled="true">" and define the coordination server host and port as well. For example,

<CoordinationClientConfiguration enabled="true">
   <Servers>
       <Server host="localhost" port="2181"/>
   </Servers>
   <SessionTimeout>5000</SessionTimeout>
</CoordinationClientConfiguration>            

You need to run a coordination provider server (ZooKeeper) for which the Carbon coordination feature can be installed instead of an external ZooKeeper server. You can use multiple coordination servers to handle fail-over.

When the servers are shut down in a clustered environment where multiple tasks are already registered, scheduled and run, there will be problems when the servers start up again. This is because a single server that is started first will try to schedule all the tasks in it, since that is the only server available at that moment.

The way to handle this situation in scheduled tasks is to define a 'server count parameter '. It is a certain numerical value which specifies the number of servers that should be started up, before a particular server starts scheduling any tasks. This way, you can ensure that all the required servers are started up so that the tasks can be distributed among the identified task servers. The startup server count is given by setting the Java system property task.server.count . For example,

./wso2server.sh -Dtask.server.count=3

In this example, all servers will wait until each detects three servers in total in the cluster.

Coordination Server Clustering

The coordination servers, which are Apache ZooKeeper servers, can be clustered to cater for fail over scenarios. This is done by first creating a ZooKeeper cluster configuration for each ZooKeeper server instance and starting them up. The ZooKeeper configuration can be found in $ZooKeeperROOT/conf/zoo.cfg.

In the client-side of the coordination functionality, the file <DSS_HOME>/repository/conf/advanced/coordination-client-config.xml will resemble the following code block for multiple clustered coordination server entries:

<CoordinationClientConfiguration enabled="true">
    <Servers>
       <Server host="localhost" port="2181"/>
       <Server host="192.168.0.2" port="2181"/>
       <Server host="192.168.0.3" port="2181"/>
    </Servers>
    <SessionTimeout>5000</SessionTimeout>
</CoordinationClientConfiguration>

The configuration above points to three ZooKeeper servers residing in locations: localhost, 192.168.0.2 and 192.168.0.3. All are with client port 2181.

Also refer to Adding Scheduled Tasks.