[rabbitmq-discuss] request for help!
rafaels at redhat.com
Thu May 6 16:10:00 BST 2010
Martin Sustrik wrote:
>> As part of an ongoing drive to "be more open" as well as to "get to
>> 1.0" the AMQP Working Group has published the 1-0 PR3 draft on the
>> webs for Public Comment:
> Great you are bringing this to the public attention!
> We've discussed this before, so I'm going to repeat myself for the sake
> of people on the mailing list...
> From my point of view there are two crucial issues with AMQP/1.0:
> 1. Messy layering. Almost every concept is discussed at multiple places.
> It's very hard to understand the specification in its current form. (To
> be fair, one piece is nicely and consistently separated. The codec.)
A bit more detail would help on this point. I suspect at least some of
this impression is due to the organization of the information as opposed
to the technical layering, and specifics would help tease that out.
> 2. Assumption that messages are stored on the node in unordered fashion
> shifts AMQP from being message queueing protocol to being database
> protocol. This blurs AMQP's mission, makes it compete with SQL and
> causes implementation to be extremely costly and complex. We should
> follow the good old "do one thing and do it well" principle and focus on
> defining MQ behaviour rather than DB behaviour.
This isn't our intention with nodes. We're certainly not trying to say
that you MUST assume every kind of node stores all messages in an
What we're trying to say is that the messaging protocol doesn't actually
need to know anything at all about the internal behavior of a node in
order to ship messages to/from it. A node might behave as a strict FIFO
queue, or it might be a producer that generates messages whenever the
moon is full. Either way, the details are irrelevant to the process of
transferring that message across the wire. So in a real sense we're
trying to say as little as possible about nodes in general.
I think this is actually an example of strong layering and makes the
protocol very easy to implement as it is equally easy to retrofit it to
something that stores messages for archival vs something that stores
messages for distribution (or indeed something that doesn't even store
messages at all).
Additionally the symmetric nature of the protocol requires that we be
very careful about what we require of nodes in general since there is a
node at both ends of any link, which generally means the first and last
nodes in any path through the AMQP network are client applications which
can obviously behave in any way they like.
If you look at how the term "node" is used throughout the transport,
you'll see that in some sense it's really just a synonym for whatever
application happens to be using the messaging protocol, whether that
application is a queue inside a broker or some part of a client library.
I think where this does start getting a bit confused is in the messaging
book where the term "node" is used in a more specific sense to refer to
a certain kind of entity within a broker-like container. This area
should probably define more specific terms to talk about these more
specific kinds of node.
Overall I think your concerns about implementation complexity are more
related to how we define the specific types of nodes that constitute the
required set to be considered an "AMQP Broker", and this is not
something that the core protocol itself defines.
More information about the rabbitmq-discuss