On 07/07/2010 07:09 AM, Lahiru Gunathilake wrote:
Hi Rob,
Thanks for the information and I think we should wait until things are
alright with AMQP 1-0 and I am happy to contribute towards clustering
implementation for java broker.
There are some design notes on the C++ cluster at
https://cwiki.apache.org/qpid/clusteringha.html
It's a little dated but still mostly relevant. I am contemplating a significant
refactor to address some of the limitations mentioned in the design doc, in
particular the maintainability issues.
I don't know how much we can share between the C++ and Java implementations, we
may be able to share some architecture/design principles or at the very least
learn from the problems encountered in the C++ cluster and avoid repeating them
in Java :)
The C++ cluster is organized around the concept of virtual synchrony, if the
Java broker uses the same concept then we have a chance to share some design
principles. (A quick google shows up http://freshmeat.net/projects/evs4j)
Virtual synchrony simplifys life a lot in trying to design replication code as
it provides guaranteed ordering of messages to all nodes and uses an efficient
UDP transport for multicasting. IMO it would be *extremely* difficult to achieve
N>2-way replication starting from scratch over TCP or UDP.
As I said, I have in mind some refactoring of the existing C++ cluster, which
I'll try to write up soon, so now is a great time to bounce ideas around as far
as I'm concerned.
On Wed, Jul 7, 2010 at 3:25 PM, Robert Godfrey<[email protected]>wrote:
Currently what I am thinking is achieving HA without loosing messages
which
is the basic requirement of any clustering approach.
So this we can only really achieve with 0-10 or 1-0 (as per my
previous post, AMQP 0-8/0-9/0-9-1 don't have any sort of
acknowledgement on publish which makes it impossibly to guarantee any
sort of reliability except in the case of transactions).
Thanks a lot Robert for your reply. can you please elaborate little bit
on
why should we wait until the AMQP 1-0 support is finished, if there's a
pretty good reason for that we can wait until it comes up.
AMQP 1-0 defines a clearer model for which state needs to be retained
in order to recover from temporary failure. Given the architectural
changes inherent in supporting AMQP1-0 and the fact that AMQP1-0
should be the basis of Qpid efforts going forward, I would much rather
design any state replication around the 1-0 model than earlier models
of the protocol. Moreover while we are re-architecting for 1-0 we can
have clustering in mind.
If we want a "quick and dirty" solution for right now, I would look at
active-passive and replication of the "MessageStore" - this should be
achievable... and will give you the same sort of reliability that you
get from persistent messages.
-1, since we don't have to wait years for this i guess, so let's do that in
correct approach, I do not have a quick requirement with is and I consider
this as a nice to have feature which is good when it comes to marketing Qpid
infront of clients.
Lahiru
-- Rob
---------------------------------------------------------------------
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]
