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.. > > 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. > > 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?. 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
