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, basically this boundary of separation must be defined somehow. So considering all these cases, for us, the cleanest way is to create our own group functionality to implement this, so it covers all the required scenarios.
Cheers, Anjana. On Tue, Apr 1, 2014 at 2:32 PM, Afkham Azeez <[email protected]> wrote: > According to the proper definition of coordinator, a single cluster may > generally have only one coordinator. So when your "coordinators" fail, how > do others take over those tasks? Rather than having each component > implement this in different ways, I would prefer the kernel to decide who > the coordinator is, and then notify the relevant components. > > Azeez > > > On Tue, Apr 1, 2014 at 2:27 PM, Anjana Fernando <[email protected]> wrote: > >> Hi Azeez, >> >> For the tasks functionality, at the moment, we have our own >> implementation on top of Hazelcast, since we require some additional >> functionality than the simple scenario. The idea was I guess, to build that >> functionality on top of this, but the direct implementation for the moment >> is more straight forward. For example, the task implementation currently >> can have multiple coordinators according to different task types, this is >> because a single node can be hosting tasks for many tasks types and another >> may only contain a different task type and so on. So we will see probably >> in the future, if we can migrate to this, by possibly implementing any >> missing functionality. >> >> Cheers, >> Anjana. >> >> >> On Tue, Apr 1, 2014 at 1:52 PM, Afkham Azeez <[email protected]> wrote: >> >>> We have had this requirement for having a single coordinator per >>> cluster, and I have come up with a simple implementation. I am using a >>> Hazlecast lock for this. The member who acquires this lock becomes the >>> coordinator. In the event of the coordinator crashing, another member will >>> acquire that lock, and will become the new coordinator. When a new member >>> becomes the coordinator, then it may need to do certain things. For >>> example, the tasks component may need to take over execution of tasks. In >>> order to notify such components about this member becoming the coordinator, >>> I have introduced an interface called CoordinatedActivity with a single >>> method called execute. If you wish to be notified when this member becomes >>> the coordinator, you need to register an OSGi service which implements that >>> interface. >>> >>> In addtion, the ClusteringAgent also has a method named isCoordinator >>> and if your code wishes to check whether this member is the coordinator >>> before executing certain things, you can call that method. >>> >>> The code is available in the feature branch >>> https://github.com/wso2/carbon-kernel/tree/cluster-coordinator-feature >>> >>> -- >>> *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 <%2B94%2077%203320919> 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* >>> >> >> >> >> -- >> *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 <%2B94%2077%203320919> 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* > -- *Anjana Fernando* Technical Lead WSO2 Inc. | http://wso2.com lean . enterprise . middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
