IMO if our ELB is there and it has MB then one can consider using that MB. The main point is to move away from "cluster messages" for deployment synchronization across a cluster of machines. In fact many people won't use this at all and will do depsync by simple file copy!
So there's no point in debating whether MB runs in the manager or in the ELB: if we go with this model we are assuming there's a messaging system in place always and we (carefully) use topics to broadcast relevant info. I haven't seen anyone objecting .. is that correct? If so what are the implications? Where's the depsync code? IMO it should not be in kernel at all. Sanjiva. On Sat, Sep 14, 2013 at 10:55 AM, Nirmal Fernando <[email protected]> wrote: > > > > 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 > > -- Sanjiva Weerawarana, Ph.D. Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
