On 09/24/2010 12:11 PM, Gordon Sim wrote:
On 09/22/2010 10:35 PM, Alan Conway wrote:
I'm proposing a redesign of the C++ cluster, this is how I would have
done it in the first place if only I had known...
Here's an initial writeup:
https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/cluster/new-cluster-design.txt
I like your ideas; sounds like the right direction to me. Revising the
interface/mechanism around asynchronous completion of enqueue/dequeue as used by
the store seems like one key first step.
There are two components to this design, (a) replication of message state and
(b) coordination of the queue locking/ownership. Keeping these separate and
behind minimal interfaces will I think allow for a lot of flexibility.
For example there is nothing in the message state replication that requires
multicast or even virtual synchrony, so it could be possible to use that same
interface for replication over a WAN to a DR site (eliminating the need for the
so called 'asynchronous queue state replication' we have partially implemented
now).
Also the queue ownership mechanism in the simplest case can allow for
active-passive configuration; with ownership transferring only on failure of the
primary.
The similarity between replication and persistence of message state is also
worth pursuing. Can the store and the cluster share the same interface to the
queue? Tracking acquisition as a distinct step is not something the store does
at present, but at some level (at some point?) at least it could be useful.
As observers of the queue I think store & cluster can use the same callback API
i.e. MessageStore, with a few extensions e.g. acquisition. Current store
implementations would just ignore the acquisition callbacks.
On more specific comment:
*** Requirements
The cluster must provide these delivery guarantees:
- client sends transfer: message must be replicated and not lost even if the
local broker crashes.
- client acquires a message: message must not be delivered on another broker
while acquired.
- client rejects acquired message: message must be re-queued on cluster and
not lost.
That should perhaps be 'releases' rather than 'rejects'? Reject is also an
interesting case, but currently rejected messages are not requeued, they are
delivered to the alter-nate exchange for the queue if defined (i.e. the
dead-lettering mechanism defined in 0-10) or dropped if not.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
Updated new-cluster-design.txt for this.
I'll work on fleshing out the interfaces & interactions in more detail.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
