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
