On Sat, Sep 14, 2013 at 10:42 AM, Supun Malinga <[email protected]> wrote:
> Hi Nirmal, > > On Sat, Sep 14, 2013 at 10:19 AM, Nirmal Fernando <[email protected]> wrote: > >> Hi Supun, >> >> Here's my thoughts. >> >> ELB != clustering / cluster messaging >> > true, not what I meant actually, rather, ideally since when we got away > with clustering, we could not be dependent on the ELB as well. > > >> >> In most of the deployments today/tomorrow, you will need a load balancer. >> > > LB won't always be our ELB.. > Ya, that's why I mentioned 'a load balancer'. > >> And if you think from a user point of view, adding a new MB server in >> order to get depsynch is not accepted *always*. >> > > Yes for that we will have the embedded MB (minimized) on the products. > How would LB get to know about the members? By pointing to each embedded MB statically. IMO it's better to minimize the static links. >> What I suggested was, >> >> since (ELB == a Carbon server) --> ELB also has a embedded MB features >> --> You can run topics inside ELB >> >> Hence, in a deployment, where ELB involves, you can use its embedded MB >> for communication, instead of using MBs in each mgt node. That way ELB gets >> to know the topology dynamically and all other nodes in the system should >> only need to know ELB (we can think this as well known node of the system). >> > > So how are we going to do the deployment in a smallar setup where there is > no ELB or a different LB is used?. > If it's a different LB, I don't think there's much choice than statically defining members. > > thanks, > >> >> >> On Sat, Sep 14, 2013 at 10:04 AM, Supun Malinga <[email protected]> wrote: >> >>> Hi Nirmal, >>> >>> IMO we shouldn't involve ELB for this. Main reason to move to MB based >>> depsync is to move out of the cluster messaging dependency and >>> communication issues with that. Here itself we should not again complicate >>> the process involving ELB. IMO depsync and ELB relationship is not logical. >>> In a smaller deployment mgt node should have the MB capabilities and in a >>> larger deployment we can have a separate MB for the purpose.. >>> >>> thanks, >>> >>> >>> >>> >>> On Sat, Sep 14, 2013 at 8:33 AM, Isuru Haththotuwa <[email protected]>wrote: >>> >>>> On Fri, Sep 13, 2013 at 10:20 PM, Nirmal Fernando <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Sep 13, 2013 at 5:06 PM, Pradeep Fernando <[email protected]>wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> During the recent depsync related meeting, the above $subject came >>>>>> up.. >>>>>> here are the some of the discussion points. >>>>>> >>>>>> - Currently our depsync setup uses cluster messages to send the >>>>>> repository sync message >>>>>> - Message loss is a one issue with the current approach. message >>>>>> replaying can be done, but not the proper way to do it. >>>>>> - We can use JMS/MB as the communication mechanism between depsync >>>>>> nodes. >>>>>> - the solution scales well, message persistence is there by default. >>>>>> >>>>>> Approach, >>>>>> >>>>>> - We ship a embedded MB server with our every product. (p2 feature >>>>>> installation is one/server profile/ etc is open for discussion) >>>>>> - manager node starts up the MB server, worker nodes read from it. >>>>>> - LB can load balance across cluster either using static endpoints or >>>>>> can get the endpoint details from the MB itself - LB doe not have to use >>>>>> clustering anymore.. >>>>>> >>>>> >>>>> Using static endpoints is not suiting for a scaling dynamic >>>>> environment. In the case of having our ELB, we could create a topic per a >>>>> cluster within ELB and then let nodes subscribe to the well known ELB's >>>>> matching topic. >>>>> >>>>> If there's no LB involved, one mgt node can create a topic which >>>>> corresponds to its domain and then let other nodes subscribe to this Well >>>>> known topic. >>>>> >>>> >>>> Or we can allow configuring the topic names based on whatever the >>>> clusters that would be there. ELB can too subscribe to a topic in the same >>>> MB (or whatever the communication bus) so that it can receive information >>>> on endpoints dynamically. >>>> >>>>> >>>>>> >>>>>> Concerns, >>>>>> >>>>>> How are we going to incoperate these changes to future releases. >>>>>> Deployment is part of the carbon kernel. If we are to implement above >>>>>> there >>>>>> are kernel changes. what is the expected release version, >>>>>> >>>>>> thanks, >>>>>> --Pradeep >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks & regards, >>>>> Nirmal >>>>> >>>>> Senior Software Engineer- Platform Technologies Team, WSO2 Inc. >>>>> Mobile: +94715779733 >>>>> Blog: http://nirmalfdo.blogspot.com/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks and Regards, >>>> >>>> Isuru H. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> >> Thanks & regards, >> Nirmal >> >> Senior Software Engineer- Platform Technologies Team, WSO2 Inc. >> Mobile: +94715779733 >> Blog: http://nirmalfdo.blogspot.com/ >> >> >> _______________________________________________ >> 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 > > -- Thanks & regards, Nirmal Senior Software Engineer- Platform Technologies Team, WSO2 Inc. Mobile: +94715779733 Blog: http://nirmalfdo.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
