[rabbitmq-discuss] Fw: high availability solutions?

[Jason J. W. Williams]

Hey Matthew,

> I may as well just attach the full documentation as it stands given
> otherwise snippets of it will just leak out.
>
> Obviously please bear in mind this may change before release, though not
> in any profound ways (unless the release is delayed for a few years).

Thank you for the docs! Overall it looks like a big step up. All of
your hard work on this is very much appreciated. I do have a few
questions/comments on it:


* The fact that messages in a transactions published to a mirrored
queue are silently dropped is inevitably setting up a customer to lose
messages when they forget about that property. Why not error out the
transaction so the problem is actively in their face, or at least give
it a best effort?

* If publishes are parallel to the master queue and it's slaves, how
are consumes and other actions that are slaved serially off the master
able to keep the slaves in sync since you're mixing parallel ops with
serial ones?

* If consumers are going to be considered disconnected, why aren't
they actually disconnected so they can use their assumptions about
lost connections to assume acknowledgements in flight were lost etc
(and re-use app logic they already have)?

* The lack of synchronization for new Q slaves is a bummer,
particularly in the case where a rejoining slave tosses it's durable
messages regardless of whether those message have actually been
consumed. It seems like there should be a history log shared across
the masters and slaves so a rejoining slave can sync up off the master
and reconcile it's durable contents.

* Why do mirror slaves have to be specified by node name, rather than
just passing a "numCopies=X" to the queue on creation and letting the
cluster handle the distribution? It seems to be shifting complexity to
the client that should be in the cluster which has the best knowledge
of how many members exist and other internals.


-J