[rabbitmq-discuss] request for help!

[Michael Bridgen]

>>     Let me give you just one example of what problems we are facing
>>     here: Destructive vs. non-destructive semantics break "stability" of
>>     message dispatch algorithm. In other words, which messages you get
>>     is not fully determined by your subscription, rather it depends on
>>     ordering of subscriptions in the broker. If destructive subscription
>>     is matched first, non-destructive subscription won't get the
>>     message. If they are matched in reverse order, both get the message.
>>     You do expect such behaviour with DB system -- ordering of SQL
>>     statements effects the results -- however, you don't want it to
>>     happen with MQ system.
>>
>>
>> If you use destructive links at all then obviously (and correctly) which 
>> messages are sent to which consumers will depend completely on the order 
>> in which the node offers the messages to the links.  This is the epected 
>> behaviour for queues.  For instance a shared work queue Q with consumers 
>> A, B and C ... when a message M enters the queue it is the choice of the 
>> node which of the A, B, or C it offers the message to - the other two 
>> will never see it.  So I disagree that this is not expected behaviour in 
>> Messaging.  What you seem to be describing above is "routing" where 
>> there is no storage capability.
> 
> Let me give an example:
> 
> Say you have a non-destructive an destructive links attached to a node. 
> When you process a message at the node, the non-destructive link gets 
> either all the messages (if the matching for the destructive link is 
> done after matching for the non-destructive one), or no messages (if the 
> matching for the destructive link is done before matching for the 
> non-destructive one) or random subset of messages (if some form of 
> load-balancing among links is done). All in all, client has no guarantee 
> of which messages it'll get or whether it'll get at least some messages.
> 
> In other words, one misbehaved client can render all the other clients 
> non-functional.

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.

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.

(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. ...")


Michael.