With the new Hazelcast based clustering implementation, in fact, cluster messaging is done using a Hazelcast topic the same pub/sub semantics. So, do we really need to use MB?
What are the advantages of MB compared to Hazelcast topics? Azeez On Sun, Sep 15, 2013 at 8:08 AM, Sanjiva Weerawarana <[email protected]>wrote: > 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 > > -- *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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
