Hi Prabath, Great, and by the way, the ntask component is working perfectly fine, and it has been integrated into G-Reg. I'm just wondering whether these changes would in anyway impact the existing component?
Thanks, Senaka. On Mon, Mar 26, 2012 at 1:19 PM, Prabath Abeysekera <[email protected]>wrote: > > > On Mon, Mar 26, 2012 at 12:45 PM, Tharindu Mathew <[email protected]>wrote: > >> 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. >> >> > +1. I'll work on that. > > >> >> 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 >> >> > > > -- > 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 > > -- *Senaka Fernando* Product Manager - WSO2 Governance Registry; Associate Technical Lead; WSO2 Inc.; http://wso2.com* Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando *Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
