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. > 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. > > When the task server code was implemented, the idea was to do it as part of that component because clustering didn't have coordinator functionality. With C5 since we are implementing this, I would prefer to do this in a proper manner so that it is done in a standard way across the platform rather than each component doing it in its own way. If the current coordinator framework we have created is incapable of catering to your requirement, the best way to do it would be to improve that code in the kernel. One of the things we are relying on is not to take too much of a hard dependency on Hazelcast and rely as much as possible on our clustering APIs. We did that when we used Tribes and it made it very easy to switch to Hazelcast because none of the component code was directly coupled with Tribes. > 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 > -- *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
