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

Reply via email to