I'm OK to have a separate API to handle the task stuff, but in that case will it have access to Hazelcast or other internal stuff? and should it be a part of kernel ?
I'm not sure what are the bits and pieces we need from Hazelcast to create this API and exposing all of them will make the Caching API ugly :) Regards, Suho On Fri, Jan 17, 2014 at 11:44 AM, Supun Malinga <[email protected]> wrote: > 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 > > -- *S. Suhothayan* Associate Technical Lead, *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | 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
