Hi Azeez, Well I used the word 'could' loosely there .. I gave the reasons for the group functionality :) .. I just think it would be a useful functionality for many use cases ..
Cheers, Anjana. On Fri, Jan 17, 2014 at 9:30 AM, Afkham Azeez <[email protected]> wrote: > > > > On Fri, Jan 17, 2014 at 10:42 PM, Anjana Fernando <[email protected]> wrote: > >> Hi, >> >> Yeah, most probably, the task related functionality should not be part of >> this API, but the group functionality I mentioned *could* be useful, as >> I explained. >> > > The golden rule about API design is "when in doubt, leave it out" ( > http://www.infoq.com/articles/API-Design-Joshua-Bloch) > > >> >> Cheers, >> Anjana. >> >> >> On Fri, Jan 17, 2014 at 4:08 AM, Kishanthan Thangarajah < >> [email protected]> wrote: >> >>> IMO, I think task related APIs are not part of kernel or clustering APIs >>> provided by the kernel. Since this is more of a use-case on functions >>> provided by the hazelcast, we can expose the underline hazelcast instance >>> as an OSGi service which then can be used for the above purpose. >>> >>> >>> On Fri, Jan 17, 2014 at 12:42 PM, Sriskandarajah Suhothayan < >>> [email protected]> wrote: >>> >>>> 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 <%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 >>>> >>>> >>> >>> >>> -- >>> *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>* >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > *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 > > -- *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
