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
