[rabbitmq-discuss] request for help!

Thu May 6 16:10:00 BST 2010

Martin Sustrik wrote:
> Alexis,
> 
>> 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:
>> http://www.amqp.org/confluence/download/attachments/2523279/amqp_1-0_PR3.pdf
> 
> 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 
unordered way.

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.

--Rafael