On Mon, Sep 16, 2013 at 7:17 PM, Afkham Azeez <[email protected]> wrote:
> 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? > Another aspect to think about is that for MB in memory mode, in the future, we could end up using Hazelcast topics/queues. If so, shifting from cluster messaging to MB would not make that much of a difference. > > > 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* > -- *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
