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? > > >> >> >>> 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. >> > > Yes, I'm +1 for this, I also believe there should be only clustering API > with the required functionality. I've explained the scenarios several > times, please check mail threads "[Architecture] [C5] Clustering API" and > "New clustering APIs that are required". Basically the group functionality > is required for our use cases. And implementing this functionality on top > of the current suggested approach is not straight forward, that is, it is > not straight forward to layer the required functionality on top of this > one, in that situation, we had no choice but to directly implement it. But > anyways, lets try to work together a bit and come with a better API if > possible to cater all the requirements. > > Cheers, > Anjana. > > >> >> >>> 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 <%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
