David Ingham wrote:
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: aidan.skin...@gmail.com [mailto:aidan.skin...@gmail.com] On Behalf Of
Aidan Skinner
Sent: Friday, February 20, 2009 12:20 PM
To: dev@qpid.apache.org
Subject: Re: want to contribute ;)
On Fri, Feb 20, 2009 at 7:17 PM, Alan Conway <acon...@redhat.com> 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.
he C++ broker uses the CPG protocol from openais (now corosync) to provide a
virtual synchrony engine, there's no Java version. If the java broker also uses
virtual synchrony and follows the approach used by C++ brokers (which is mostly
just AMQP) then it's possible at at some future date we can find a vitual
synchrony engine that that's compatible for both. However I'm not sure there's a
real need for mixed C++/Java reliability clusters. Federation is a different
story, I think it would be good to get that working across languages.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
