[rabbitmq-discuss] request for help!

Thu May 6 17:04:50 BST 2010

Michael Bridgen wrote:
> I understand that there's a desire to accommodate e.g., JMS-like 
> semantics (which I can see may have been a motivating force for 
> "distribution mode").  But I think the core spec can leave room for 
> those, without taking a position otherwise.
> 
> What the spec does at the minute is to have a model that tries to 
> encompass all possibilities, where it ought to be silent.

I don't think this is really related to JMS at all. If you accept that 
certain kinds of nodes store messages, then it generally makes sense 
that you would want to be able to inspect the messages stored at a node 
without actually destroying them.

Now JMS does require this capability with the notion of "queue 
browsing", however we could easily define a way to create this sort of 
link in the JMS Mapping via the extension points in sources, however 
that would be incorrect as that would be assuming that JMS is the only 
API in the world that wants to provide this capability, it therefore 
makes sense to have a standard way to request non-destructive access to 
stored messages that sits somewhere outside the JMS Mapping.

Note that this is *not* requiring every node that stores messages to 
support non-destructive access, it merely says if you *do* support 
non-destructive access, here is a standard way to expose that capability.

> The main problem with the "all possibilities" approach is that it 
> infects other layers.
> 
> For example, the distribution modes and message state model make flow 
> control, transactions, responsibility transfer and reliable delivery all 
> interdependent.  In my opinion these can be teased apart; specifically 
> (but probably not exclusively), by distinguishing between delivery 
> acknowledgement and transfer of responsibility.

Can you explain this a bit more? In PR3, flow control and acknowledgment 
are independent in that you can ack messages without causing more to 
arrive, and you can cause more to arrive without acking. Is there some 
other sense of interdependence that you mean here?

> (Conflating those causes problems in 0-9-1 too by the way -- there's a 
> rather fraught, unresolved question in RabbitMQ's bugzilla about the 
> interaction between flow control and transactional acks.  The last 
> comment says "In conclusion, after discussion, acks are overloaded, and 
> mean two things - 1. I've seen the msg; 2. forget about the msg. ...")

I don't see how (1) is ever semantically meaningful to communicate. In 
the context of a transaction an ack isn't actually saying (1), it's 
generally saying something like "forget about this message when the 
transaction commits". Following that, it's the commit of the transaction 
that causes (2) to happen, and this may well happen entirely out of band 
of the messaging layer.

--Rafael