Hi Azeez, On Thu, Jul 4, 2013 at 2:01 PM, Afkham Azeez <[email protected]> wrote:
> > 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. > Yep, sure, I was also thinking the same. Cheers, Anjana. > >> 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* > -- *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
