The reason that ntask expects string key value pairs is to be able to execute tasks in a distributed manner. As part of completing the task, you should setup a few nodes and check whether tasks are distributed appropriately and in a fail over manner.
Also, try to expose some MXBeans to check how many tasks are running, memory/IO per task, etc. We have to think of monitoring the monitor scenario. On Mon, Mar 26, 2012 at 12:28 PM, Buddhika Chamith <[email protected]>wrote: > > On Mon, Mar 26, 2012 at 12:04 PM, Prabath Abeysekera <[email protected]>wrote: > >> Hi all, >> >> I've been working on the $subject and currently there's only one task >> remaining to be completed. The main intention of this effort is to migrate >> the existing task implementation of BAM to ntasks which is a quartz based >> task scheduler component introduced a couple of months back. While working >> on the aforementioned bit of remaining work, I was confronted with an issue >> and here's my suggestions to overcome it. >> >> In the currently used BAM task implementation, there's a mechanism called >> DataContext which is used to pass some runtime data to a particular task >> execution (such as default credentials to log into cassandra, tenant ID, >> etc) and to populate it with records that are fetched from cassandra (using >> the GetAnalyser) in memory. Whenever a task is scheduled this object is >> passed into it which then uses the DataContext object to grab the necessary >> runtime information required for the task execution. Ntasks being a generic >> task scheduler component, only accepts a map of string key value pairs as >> run time properties. In other words, if it is required to pass additional >> set of properties apart from the ones that are provided by default (for >> example, cron expression, task count, task interval, etc) then they have to >> be passed as Strings. Thus, we either need to serialize the DataContext or >> we need to find some other mechanism to pass those properties in the >> DataContext to the corresponding task. >> >> > Currently the DataContext is used as a holder for data fetched from > Cassandra and so the serializing of DataContext is not trivial and not very > useful as well. > > IIUC, I believe it would be more appropriate if it is possible to make the >> DataContext local to the task execution since a task being a single >> independent execution unit and the DataContext is also bound to a >> particular task. To elaborate more on this, the DataContext seems to be >> effectively used in the task execution phase, so I believe, there's a >> possibility for us to build it up at the aforementioned phase without >> initializing it in the task scheduling phase. This way we can even get rid >> of the usage of the binding of DataContext at the task scheduling phase. >> And we can also pass the properties of the DataContext as String key value >> pairs as well. >> > > +1. This decouples run time data and configuration data currently present > in the DataContext. We can basically use DataContext for holding run time > data (basically fetched data) which would be specific for the particular > execution of the task. > > >> Had an offline chat with Tharindu on this and we agreed to proceed with >> the above suggested mechanism which involves removing the binding of the >> DataContext object at the task scheduling phase. >> >> >> >> Regards, >> -- >> Prabath Abeysekara >> Software Engineer >> WSO2 Inc. >> Email: [email protected] <[email protected]> >> Mobile: +94774171471 >> >> <http://harshana05.blogspot.com/> >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > Regards > Buddhika > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Regards, Tharindu blog: http://mackiemathew.com/ M: +94777759908
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
