On Thu, Jul 4, 2013 at 1:58 PM, Anjana Fernando <[email protected]> wrote:
> Hi, > > Yeah, we should have a single API. So as said in the other thread, next > release would be in October, which will be too late for us. We will need to > create our own API until then. > Perhaps you can implement that is a generic manner, so that once the kernel is ready, we can use parts of it. > > Cheers, > Anjana. > > > On Thu, Jul 4, 2013 at 1:16 PM, Afkham Azeez <[email protected]> wrote: > >> It is cumbersome to have two clustering APIs; one from Axis2 & one from >> Carbon. There are redundant methods, and conflicting stuff. This is why I >> was thinking about bringing in only a Carbon based API for this release. >> So, until the next release, I am not planning to continue further work on >> the Carbon clustering API. >> >> Azeez >> >> >> On Thu, Jul 4, 2013 at 1:01 PM, Anjana Fernando <[email protected]> wrote: >> >>> 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 >>> >> >> >> >> -- >> *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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
