Hi Azeez,
On Mon, Sep 16, 2013 at 11:42 PM, Afkham Azeez <[email protected]> wrote: > > > > 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? > I'm sorry about the confusion. I meant Tribes related issues and I was trying to say if we can overcome all issues we had with *Tribes* by the new *Hazelcast* based clustering implementation, we can consider using Hazelcast instead of an MB. > >> >>> >>>> >>>> >>>> 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 > > -- 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
