On Mon, Sep 16, 2013 at 11:20 PM, Isuru Perera <[email protected]> wrote:
> > > > On Mon, Sep 16, 2013 at 8:05 PM, Afkham Azeez <[email protected]> wrote: > >> >> >> >> 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. >> > Yes! If we can overcome current DepSync issues with Hazelcast, there will > be no point in going for an MB. > What are the current Hazelcast related depsync issues? > >> >>> >>> >>> 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 >> >> > > > -- > Isuru Perera > Senior Software Engineer | WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > about.me/chrishantha > > _______________________________________________ > 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
