Hi Azeez, I guess, we got the cluster domains and the Group concept confused here. Anyways, yeah, I agree, if this is only a generic API, there doesn't need to have the Group concept here. The low level operations would be fine. We can perhaps build on those to create the Group features. But here, we maybe getting similar functionality we will need with the "ClusterMessage" interface I guess.
So what I basically asked earlier was, how we are receiving the message to a node, earlier in my Group example, we have a separate interface, the GroupEventListener interface, which has a callback, which is being called when a message is coming to the group. I guess this is not the approach you're using, rather, the same approach we had in the old clustering API, which was, the same "ClusterMessage" object's some method would be automatically called, when a message comes in, which is actually more convenient. So with this approach, we will not have to do our own routing of the messages, and a specific ClusterMessage implementation will have its own application, e.g. Tasks component's messages. So anyhow, if I understood it correctly, we should be able to get our requirement fulfilled also without much trouble. Also, since you mentioned the response for a message, in the earlier clustering API, we did have a way to get the response right directly? .. without going through an asynchronous mechanism like what you suggested here. Basically, we need the requirement to do RPC style invocations, that is returning a response immediately by blocking the callee. Or else, this would be a bit hard to implement for some scenarios in an async way. And just for the clarification, can you put the definition of the "ClusterMessage" interface here. Cheers, Anjana. On Thu, Jul 4, 2013 at 12:13 PM, Afkham Azeez <[email protected]> wrote: > One member joining multiple groups is not something that is generally > done. This means that such a node is a member of multiple clusters. > However, even in the WSO2 clustering design, we have special members who > are group management agents, who join multiple groups for special purposes. > ELB is such a member. However, we cannot make that generic where a node > joins multiple clusters. Looks like this is something specific to your use > case, and such specific requirements cannot be incorporated into a generic > API. > > Message sending between members is not an issue; the API will allow you to > send it to either a selected group of members or the cluster (all members). > If you are expecting a response to a message, then there needs to be some > correlation logic which will correlate the response to the request. For > such a case, we need each message to carry a UUID. > > Azeez > > Azeez > > > On Thu, Jul 4, 2013 at 12:06 PM, Anjana Fernando <[email protected]> wrote: > >> Hi Azeez, >> >> In your solution, how would a specific member be joining a group, that is >> how will he part of a specific cluster domain, and then basically, how will >> he be receiving messages destined for him, either direct peer-to-peer ones >> or broadcast messages. >> >> Cheers, >> Anjana. >> >> >> On Wed, Jul 3, 2013 at 7:37 PM, Afkham Azeez <[email protected]> wrote: >> >>> >>> >>> >>> On Sun, Jun 23, 2013 at 7:38 PM, Manoj Kumara <[email protected]> wrote: >>> >>>> Hi Azeez, >>>> >>>> +1 for the approach. >>>> >>>> As we discussed the concept of Group will be useful during >>>> the implementation of 'Operations Center'. Based on current requirements >>>> what we need is to discover the members of the group and to send cluster >>>> messages to selected set of members. I think it will be possible with the >>>> requirements given by Anjana. >>>> >>> >>> In the case of Operations Center, it is not part of any cluster & sits >>> outside. So the group in OC will be separate from the clustering API. >>> Actually, OC will not be using the clustering API, but the manager nodes in >>> each cluster will be using this API. >>> >>> >>>> >>>> Thanks, >>>> Manoj >>>> >>>> Best Regards.. >>>> >>>> >>>> Manoj Kumara >>>> Software Engineer >>>> WSO2, Inc.; http://wso2.com >>>> >>>> Twitter: http://twitter.com/ManKuma >>>> Mobile: +94713448188 >>>> >>>> >>>> On Sun, Jun 23, 2013 at 10:36 AM, Anjana Fernando <[email protected]>wrote: >>>> >>>>> Hi Azeez, >>>>> >>>>> We basically need a concept of a Group, where we can discover members >>>>> of that specific group, send messages between peers, send broadcast >>>>> messages to all the members, and also get group member notifications, such >>>>> as a member arriving to a group, and a member leaving. >>>>> >>>>> A single server should be able to join multiple Groups basically, with >>>>> a given name, I guess this is the same concept of domains we have in the >>>>> current clustering API. This is required when a single server can act >>>>> multiple roles, so a server can join the groups it require. >>>>> >>>>> Also another requirement that is needed is, we need to be notified >>>>> when a specific group acquires a specific number of group members. This >>>>> can >>>>> be either implemented using a blocking method (with a timeout possibly) >>>>> which waits for a specific number of members to arrive, or by registering >>>>> a >>>>> callback. This type of functionality is required for a scenario like, when >>>>> scheduling tasks, we need a specific number of servers to be startup up, >>>>> to >>>>> spread the tasks throughout the cluster, without giving all the tasks to >>>>> the 1'st server that starts up, I'm sure, this requirement would arise for >>>>> other components also. >>>>> >>>>> Please check for the Group API ([1],[2] I've created for the >>>>> coordination component to get the above functionality (ignore the >>>>> "clearGroupMessages" method there). There, in [2], for "onPeerMessage", I >>>>> guess it's useful for us to get the member id who would have sent the >>>>> message. Same for "onGroupMessage", and also, there we could possibly >>>>> return a result from that node, and give a accumulated result to the >>>>> sender, which I guess we already do in the current clustering API. >>>>> >>>>> [1] >>>>> https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.0.0/components/coordination/org.wso2.carbon.coordination.core/4.0.5/src/main/java/org/wso2/carbon/coordination/core/sync/Group.java >>>>> [2] >>>>> https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.0.0/components/coordination/org.wso2.carbon.coordination.core/4.0.5/src/main/java/org/wso2/carbon/coordination/core/sync/GroupEventListener.java >>>>> >>>>> Cheers, >>>>> Anjana. >>>>> >>>>> >>>>> On Sun, Jun 23, 2013 at 9:50 AM, Afkham Azeez <[email protected]> wrote: >>>>> >>>>>> Folks, >>>>>> Please let me know through this mail thread if you require any new >>>>>> clustering APIs. It would be good if you could give the required >>>>>> method signature or describe the scenarios you need to be covered. >>>>>> >>>>>> Azeez >>>>>> >>>>>> -- >>>>>> Afkham Azeez >>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>> >>>>>> email: [email protected] cell: +94 77 3320919 >>>>>> blog: http://blog.afkham.org >>>>>> twitter: http://twitter.com/afkham_azeez >>>>>> linked-in <http://twitter.com/afkham_azeezlinked-in>: >>>>>> http://lk.linkedin.com/in/afkhamazeez >>>>>> >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Anjana Fernando* >>>>> Technical Lead >>>>> WSO2 Inc. | http://wso2.com >>>>> lean . enterprise . middleware >>>>> >>>> >>>> >>> >>> >>> -- >>> *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 >>> 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* >>> * >>> * >>> *Lean . Enterprise . Middleware* >>> >> >> >> >> -- >> *Anjana Fernando* >> Technical Lead >> WSO2 Inc. | http://wso2.com >> lean . enterprise . middleware >> > > > > -- > *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 > 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* > * > * > *Lean . Enterprise . Middleware* > -- *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
