Below contains the DSS classes that are used for implementing the DSS scheduled tasks based on ntask.
* Package "/media/data/dev/wso2/carbon/trunk/components/data-services/org.wso2.carbon.dataservices.core/src/main/java/org/wso2/carbon/dataservices/core/task". * DSS Admin Service "/media/data/dev/wso2/carbon/trunk/components/data-services/org.wso2.carbon.dataservices.core/src/main/java/org/wso2/carbon/dataservices/core/admin/DataServiceAdmin.java", check methods "isTaskScheduled", "deleteTask", "rescheduleTask", "scheduleTask", "getTaskInfo" and "getAllTaskNames". Cheers, Anjana. On Fri, Dec 9, 2011 at 6:54 PM, Anjana Fernando <[email protected]> wrote: > Hi, > > Lately I've been writing a new task component "ntask", which is directly > based on quartz2 rather than having a dependency on Synapse, and also uses > the coordination component for controlling distributing tasks in a cluster. > To facilitate this, the group communication ability in the coordination > component has been improved to contain a synchronous sendReceive call to > implement RPC scenarios between peers in the group, which is needed in the > task component. The flow simply works in the following steps, > > * Register a task description "TaskInfo", which contains task trigger > information as well. > * Schedule a registered task with the given name. > * Related task controlling operations like, reschedule, pause, resume, > delete, get status, list tasks in a specific server etc.. > > The task functionality is mainly done using a "TaskManager" interface, > which represents a task manager for a specific task type for a specific > tenant. For example, for tasks to not to clash in a server which has ESB > tasks and DSS tasks, the task type can be given to distinguish between the > two. When a task is registered, the target server, the task needs to be > scheduled can be specified by giving an implementation of the > "TaskLocationResolver" interface, where given the task context, it must > return the location of the server. There's a default task location resolver > class used otherwise when not explicitly given, which simply scheduled all > the tasks in an round robin fashion among the cluster. The failover > scenarios are implemented where, if a node goes down, the leader node will > identify it and schedule the orphaned tasks between remaining servers. > Also, if the leader node itself goes down, another node will become the > leader and reschedule the missing tasks and keep track of the running ones. > > The ntask component has a module called "solutions", which will contain > most often used task implementation. I've added a simple web service > invocation task implementation there, where in DSS itself, we derive that > to create our own tasks. So if there are simple task implementations, they > can be put into the solutions module, for reuse. > > The current ntask implementation is in-cooperated into the upcoming DSS > 2.6.3 release, so the new tasks functionality can be tested from that if > anyone's interested. > > Cheers, > Anjana. > > -- > *Anjana Fernando* > Senior Software Engineer > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > -- *Anjana Fernando* Senior Software Engineer WSO2 Inc. | http://wso2.com lean . enterprise . middleware
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
