Hi, Also in here we should consider the use cases of OC as well IMO..
thanks, On Fri, Jan 17, 2014 at 11:24 AM, Afkham Azeez <[email protected]> wrote: > 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 <[email protected] > > 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 <[email protected]> wrote: >> >>> Hi, >>> >>> On Thu, Jan 16, 2014 at 5:10 AM, Sriskandarajah Suhothayan < >>> [email protected]> 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 <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jan 16, 2014 at 4:55 PM, Kishanthan Thangarajah < >>>>> [email protected]> 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 <[email protected]> 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 < >>>>>>> [email protected]> 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: **[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* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *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: **[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* >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Anjana Fernando* >>> Technical Lead >>> >>> WSO2 Inc. | http://wso2.com >>> lean . enterprise . middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> 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 >> [email protected] >> 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: **[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* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Supun Malinga, Senior Software Engineer, WSO2 Inc. http://wso2.com email: [email protected] <[email protected]> mobile: +94 (0)71 56 91 321
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
