On Tue, Apr 1, 2014 at 5:13 PM, Anjana Fernando <[email protected]> wrote:
> Hi, > > > On Tue, Apr 1, 2014 at 4:36 PM, Afkham Azeez <[email protected]> wrote: > >> >> >> >> On Tue, Apr 1, 2014 at 3:34 PM, Anjana Fernando <[email protected]> wrote: >> >>> Hi Azeez, >>> >>> On Tue, Apr 1, 2014 at 3:31 PM, Afkham Azeez <[email protected]> wrote: >>> >>>> >>>> >>>> >>>> On Tue, Apr 1, 2014 at 3:28 PM, Anjana Fernando <[email protected]>wrote: >>>> >>>>> Hi Azeez, >>>>> >>>>> On Tue, Apr 1, 2014 at 3:09 PM, Afkham Azeez <[email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 1, 2014 at 2:57 PM, Anjana Fernando <[email protected]>wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is basically sort of like a group/sub-group functionality we >>>>>>> use in tasks, where for each group there is a coordinator (leader). For >>>>>>> example, server nodes that maybe in the same clustering domain, but >>>>>>> still >>>>>>> different type of nodes in server functionality, for example, in BAM, we >>>>>>> have several profiles and so on. And those nodes may run different >>>>>>> types of >>>>>>> tasks, for these separate group of server nodes, it needs its own >>>>>>> coordinator. Also for example, in a specific server cluster, if someone >>>>>>> decides to install some task feature only in a subset of server nodes, >>>>>>> this >>>>>>> type of requirement is needed. And another example is with the ELB, it >>>>>>> also >>>>>>> joins our cluster, which is actually a different type of a node, and we >>>>>>> shouldn't communicate with that when our tasks are scheduled, >>>>>>> >>>>>> >>>>>> ELB is part of multiple clusters, but the coordinator lock is >>>>>> acquired only on its primary Hazelcast instance, so it will never become >>>>>> the coordinator of another cluster. >>>>>> >>>>> >>>>> But it will become a member of the other clusters, I need to avoid >>>>> that, for not to include the ELB node in another group. >>>>> >>>> >>>> What are the issues you will face if the ELB becomes a member in say an >>>> AS cluster which has the task component? Again, this ELB member will never >>>> become a coordinator. Do you distribute tasks to the members, or is it that >>>> the relevant coordinator runs the specified tasks? >>>> >>> >>> Yeah, the tasks are distributed to the members by the coordinator, and >>> the coordinator here will see the ELB node also as a possible member who >>> can be used to execute their task. >>> >>> >> If that is the case, you will be facing the same issue today, unless the >> Task component creates its own Hazelcast instance & does not use the >> HazelcastInstance OSGi service provided by the kernel. Are you creating a >> separate Hazelcast cluster? >> > > No we don't create a separate Hazelcast cluster, we avoided this by > creating our own group management functionality on top of Hazelcast, where > in ntask component, a node can host specific types of tasks, and then > later, through our API, we can list all the nodes that belongs to a > specific task type (i.e. group name). > So you are using the same HazelcastInstance that is provided by the kernel; which means that the ELB member will also be seen as a member by the task component. > > Cheers, > Anjana. > -- > *Anjana Fernando* > Technical Lead > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>* *email: **[email protected]* <[email protected]> * cell: +94 77 3320919 blog: **http://blog.afkham.org*<http://blog.afkham.org> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> * linked-in: **http://lk.linkedin.com/in/afkhamazeez <http://lk.linkedin.com/in/afkhamazeez>* *Lean . Enterprise . Middleware*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
