Hi Azeez, +1 for having a chat. Having MB is not merely to get the cluster communication sorted out, but to get a proper pub/sub based notification model in place. For example a JMS topic can be subscribed by multiple types of receiver endpoints.
Thanks, Senaka. On Tue, Sep 17, 2013 at 8:22 PM, Afkham Azeez <[email protected]> wrote: > Based on the message loss argument, in that case even our new caching > implementation has to be switched to use MB instead of Hazelcast. If Hz > cannot recover from such losses, the caches will contain obsolete values. > Caching is built on Hz maps. Cluster messaging is built on Hz topic. If you > argue that one cannot scale on the cloud & handle message losses/cluster > partitioning, then the other does not work as well. As I mentioned earlier, > depsync is only one type of cluster message. > > I would like to have a meeting next week when I return before the final > decision to move to MB is made, unless that has been already made, and this > input won't make any difference. > > Azeez > > > On Tue, Sep 17, 2013 at 8:04 PM, Afkham Azeez <[email protected]> wrote: > >> DepSync is only one type of cluster message. There are many other types >> of cluster messages. Are we proposing to use MB for those as well? >> >> >> On Tue, Sep 17, 2013 at 7:47 PM, Afkham Azeez <[email protected]> wrote: >> >>> >>> >>> >>> On Tue, Sep 17, 2013 at 11:42 AM, Eranda Sooriyabandara <[email protected] >>> > wrote: >>> >>>> Hi Azeez, >>>> >>>> >>>> On Tue, Sep 17, 2013 at 10:50 AM, Afkham Azeez <[email protected]> wrote: >>>> >>>>> Unlike Tribes, Hazelcast has been designed to scale on the cloud. All >>>>> the cluster messaging related issues we were seeing were due to Tribes, >>>>> and >>>>> Tribes was designed only for datacenter scale. >>>>> >>>> >>>> Main problem of hazelcast cluster message based deployment synchronizer >>>> is reliability. What if one node didn't get the update message? That node >>>> may not updated until next change. >>>> >>>> >>> Same thing can happen even with MB. If there is a network partition, >>> messages may not be received. But once the partitions are merged, the >>> messages that were not received should be received. Unlike Tribes, >>> Hazelcast has a good set of distributed collections, and I believe, the >>> messages posted to topics would be properly received. Adding MB just to >>> send depsync messages is overkill IMO, and the decision has been based on >>> the problems that were faced with the old Tribes based implementation. >>> >>> >>> >>>> thanks >>>> Eranda >>>> >>>> >>>>> >>>>> Azeez >>>>> >>>>> >>>>> On Tue, Sep 17, 2013 at 9:49 AM, Sanjiva Weerawarana <[email protected] >>>>> > wrote: >>>>> >>>>>> I don't see the point of marrying into Hazelcast at that level. The >>>>>> problem required here is a queuing solution because we need it to scale >>>>>> from simple to very large installations involving multiple AZs etc.. Many >>>>>> times persistent reliability is important (esp for deployment messages). >>>>>> Why would we re-invent all of that on top of Hazelcast instead of using >>>>>> MB? >>>>>> Of course we need an embedded, in-memory, ultra-light weight system too >>>>>> for >>>>>> the simple case and MB can deliver that quite easily. >>>>>> >>>>>> Sanjiva. >>>>>> >>>>>> >>>>>> On Tue, Sep 17, 2013 at 12:07 AM, Afkham Azeez <[email protected]>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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? >>>>>>>> >>>>>>>> >>>>>>> Please let us know if there are any Hazelcast related issues, >>>>>>> because we could easily get help from the Hz devs. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Eranda Sooriyabandara >>>> *Senior Software Engineer; >>>> Integration Technologies Team; >>>> WSO2 Inc.; http://wso2.com >>>> Lean . Enterprise . Middleware >>>> >>>> E-mail: eranda AT wso2.com >>>> Mobile: +94 716 472 816 >>>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>>> Blog: http://emsooriyabandara.blogspot.com/ >>>> >>>> >>>> >>>> * >>>> * >>>> >>>> _______________________________________________ >>>> 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* >> > > > > -- > *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 > > -- * <http://us13.wso2con.com/> * * * *Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com* Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando *Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
