I think this is making clustering more specific to running tasks. Handling tasks should be implemented at a layer above clustering.
On Fri, Jan 17, 2014 at 11:06 AM, Sriskandarajah Suhothayan <s...@wso2.com>wrote: > Based on the Anjana's suggestions, to support different products having > different way of coordination. > > My suggestion is as follows > > //This has to be a *one time thing* I'm not sure how we should have API > for this! > //ID is Task or GroupID > //Algorithm-class can be a class or name registered in carbon TBD > void preformElection(ID, Algorithm-class); > > //Register current node to do/join the Task denoted by the ID > void registerAsTaskWorker(ID); > > //Check is the current node is the coordinator > boolean isCoordinator(ID); > > //Get the coordinator for the ID. > NodeID getCoordinator(ID); > > We also need a Listener for Coordinator > > CoordinatorListener > > void coordinatorChanged(ID,NodeID); > > WDYT? > > Suho > > > On Thu, Jan 16, 2014 at 8:32 PM, Anjana Fernando <anj...@wso2.com> wrote: > >> Hi, >> >> On Thu, Jan 16, 2014 at 5:10 AM, Sriskandarajah Suhothayan <s...@wso2.com >> > wrote: >> >>> We also need an election API, >>> >>> E.g for certain tasks only one/few node can be responsible and if that >>> node dies some one else need to take that task. >>> >>> Here user should be able to give the Task Key and should be able to get >>> to know whether he is responsible for the task. >>> >>> It is also impotent that the election logic is pluggable based on task >>> >> >> The task scenarios are similar to what we do in our scheduled tasks >> component. I'm not sure if that type of functionality should be included in >> this API, or did you mean, you need the election API to build on top of it? >> .. >> >> Also, another requirement we have is, creating groups within a cluster. >> That is, when we work on the cluster, sometimes we need a node a specific >> group/groups. And it each group will have it's own coordinator. So then, >> there wouldn't be a single coordinator for the full physical cluster. I >> know we can build this functionality on a higher layer than this API, but >> then, effectively the isCoordinator for the full cluster will not be used, >> and also, each component that uses similar group functionality will roll up >> their own implementation of this. So I'm thinking if we build in some >> robust group features to this API itself, it will be very convenient for it >> consumers. >> >> So what I suggest is like, while a member joins for the full cluster >> automatically, can we have another API method like, joinGroup(groupId), >> then later when we register a membership listener, we can give the groupId >> as an optional parameter to register a membership listener for a specific >> group. And as for the isCoordinator functionality, we can also overload >> that method to provide a gropuId, or else, in the membership listener >> itself, we can have an additional method like "coordinatorChanged(String >> memberId)" or else, maybe more suitable, "assumedCoordinatorRole()" or >> something like that to simply say, you just became the coordinator of this >> full cluster/group. >> >> Cheers, >> Anjana. >> >> >>> >>> Regards >>> Suho >>> >>> >>> On Thu, Jan 16, 2014 at 4:56 PM, Afkham Azeez <az...@wso2.com> wrote: >>> >>>> >>>> >>>> >>>> On Thu, Jan 16, 2014 at 4:55 PM, Kishanthan Thangarajah < >>>> kishant...@wso2.com> wrote: >>>> >>>>> Adding more. >>>>> >>>>> Since we will follow the whiteboard pattern for adding new >>>>> MembershipListener's, we don't need to have the methods ( >>>>> *addMembershipListener, **addMembershipListener*) explicitly at API >>>>> level. Users will implement their MembershipListener's and register it as >>>>> an OSGi service. The clustering component will discover these and add it >>>>> the cluster impl. >>>>> >>>>> >>>> +1 >>>> >>>> >>>> >>>>> >>>>> On Wed, Jan 15, 2014 at 3:03 PM, Afkham Azeez <az...@wso2.com> wrote: >>>>> >>>>>> Anjana & Suho, >>>>>> Please review this & let us know whether these APIs address your >>>>>> requirements. >>>>>> >>>>>> Azeez >>>>>> >>>>>> >>>>>> On Wed, Jan 15, 2014 at 1:40 PM, Kishanthan Thangarajah < >>>>>> kishant...@wso2.com> wrote: >>>>>> >>>>>>> This thread is to discuss about $subject. >>>>>>> >>>>>>> Our current clustering API's contains stuffs that are mixture of >>>>>>> both user level and developer level API. We will have to separate out >>>>>>> these >>>>>>> with the clear definition. >>>>>>> >>>>>>> For clustering API (user level), we will have the following methods. >>>>>>> We can discuss clustering SPI's on a separate thread. >>>>>>> >>>>>>> * void sendMessage(ClusterMessage clusterMessage);* >>>>>>> >>>>>>> * void sendMessage(ClusterMessage clusterMessage, >>>>>>> List<ClusterMember> members);* >>>>>>> >>>>>>> * List<ClusterMember> getMembers();* >>>>>>> >>>>>>> * void addMembershipListener(MembershipListener >>>>>>> membershipListener);* >>>>>>> >>>>>>> * void removeMembershipListener(MembershipListener >>>>>>> membershipListener);* >>>>>>> >>>>>>> In here we also thought of having MembershipListener (A listener >>>>>>> which gets notified when changes occur in Membership) related API at >>>>>>> user >>>>>>> level. This will be useful when user wants to get some event >>>>>>> notification >>>>>>> when the current membership changes. Adding a new MembershipListener >>>>>>> will >>>>>>> follow the white board pattern. >>>>>>> >>>>>>> The API for MembershipListener >>>>>>> >>>>>>> * void memberAdded(MembershipEvent event);* >>>>>>> >>>>>>> * void memberRemoved(MembershipEvent event);* >>>>>>> >>>>>>> MembershipEvent will be of two types (member added or removed). >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Thanks, >>>>>>> Kishanthan. >>>>>>> -- >>>>>>> *Kishanthan Thangarajah* >>>>>>> Senior Software Engineer, >>>>>>> Platform Technologies Team, >>>>>>> WSO2, Inc. >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> Mobile - +94773426635 >>>>>>> Blog - *http://kishanthan.wordpress.com >>>>>>> <http://kishanthan.wordpress.com>* >>>>>>> Twitter - *http://twitter.com/kishanthan >>>>>>> <http://twitter.com/kishanthan>* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Afkham Azeez* >>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>> * <http://www.apache.org/>* >>>>>> *email: **az...@wso2.com* <az...@wso2.com> >>>>>> * 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* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Kishanthan Thangarajah* >>>>> Senior Software Engineer, >>>>> Platform Technologies Team, >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile - +94773426635 >>>>> Blog - *http://kishanthan.wordpress.com >>>>> <http://kishanthan.wordpress.com>* >>>>> Twitter - *http://twitter.com/kishanthan >>>>> <http://twitter.com/kishanthan>* >>>>> >>>> >>>> >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://www.apache.org/ >>>> * <http://www.apache.org/>* >>>> *email: **az...@wso2.com* <az...@wso2.com> >>>> * 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* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *S. Suhothayan * >>> Associate Technical Lead, >>> *WSO2 Inc. *http://wso2.com >>> * <http://wso2.com/>* >>> lean . enterprise . middleware >>> >>> >>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/> twitter: >>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >>> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Anjana Fernando* >> Technical Lead >> >> WSO2 Inc. | http://wso2.com >> lean . enterprise . middleware >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *S. Suhothayan* > Associate Technical Lead, > *WSO2 Inc. *http://wso2.com > * <http://wso2.com/>* > lean . enterprise . middleware > > > *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: > http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/> twitter: > http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: > http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>* *email: **az...@wso2.com* <az...@wso2.com> * 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*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
