Hi Aidan, I'm struggling to think of a business case for why I'd want to mix and match C++ and Java brokers in a cluster. I'm not pushing back; I'm just interested as to why you think this is important.
FWIW, I think that there's great value in having a common clustering design across the different language brokers, mainly to reduce overall complexity of the project as a whole, but I hadn't considered it being a requirement to mix different language versions in the same cluster. Thanks, Dave. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Aidan Skinner Sent: Friday, February 20, 2009 12:20 PM To: [email protected] Subject: Re: want to contribute ;) On Fri, Feb 20, 2009 at 7:17 PM, Alan Conway <[email protected]> wrote: > The Big Idea behind the cluster design is to separate clustering from broker > logic as much as possible by having the cluster regard the broker to a large > extent as a "black box". The cluster's job is to sort all the frames > arriving at all the nodes into a single ordered list (using virtual > synchrony). Since every node then processes the same list in the same > order, we get the same results everywhere. This design should make it possible to have heterogeneous clusters which mix C++ and Java brokers. I'm not sure that's something that we should aim for this year[1], but I think the Java implementation should take pains not to exclude this possibility. - Aidan [1] I am becoming increasingly aware that we would benefit from a publicly hashed out roadmap -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
