On Thu, Sep 19, 2013 at 5:50 AM, Afkham Azeez <[email protected]> wrote:
> > > > On Thu, Sep 19, 2013 at 5:24 AM, Sanjiva Weerawarana <[email protected]>wrote: > >> I disagree - of course caches can get out of sync .. that's part of the >> definition of being a distributed cache. However the values that you share >> in a cache are typically for performance optimization, not for reliable >> execution. >> >> On the question in your previous mail - I think we're asking this >> backwards. The first question is whether reliable messaging is necessary >> for deployment synchronization. I believe the answer that is a firm yes as >> otherwise deployment and undeployment is not reliably updated to all nodes. >> > > The follow up question is, on what basis are we assuming that cluster > messaging (publishing to a Hazelcast topic) is unreliable? (DepSync message > is a cluster message). Making an additional component such as MB for > cluster depsync to work introduces an additional deployment complexity. > When we do production deployments, HA for each & every deployment component becomes crucial. I am looking at clustering MB ( http://docs.wso2.org/display/CLUSTER420/Clustering+Message+Broker). So, if MB becomes a prerequisite for deployment synchronization, then it would make the deployment architecture much more complex. Am I missing something? > > >> >> The second question is whether you need reliable messaging for every >> interaction between nodes of a cluster. The answer to that I believe is a >> firm no. Distributed cache is a perfectly good example. >> >> Sanjiva. >> >> >> On Tuesday, September 17, 2013, Afkham Azeez 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 < >>> >>> >> >> -- >> 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
