[rabbitmq-discuss] request for help!

Thu May 6 17:07:13 BST 2010

On 05/06/2010 03:03 PM, Michael Bridgen wrote:
>> 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 would expect an implementation to define policy around where links 
with these two types of distribution mode can be used. E.g. a pub-sub 
topic might only allow non-destructive links were valid, a plain queue 
might only allow destructive links and a browsable queue might allow 
both (with what I think are then obvious if non-deterministic 
implications for concurrent links with different modes).

(I myself prefer the terms acquiring/non-acquiring to 
destructive/non-destructive, but the names used aren't critical).

> 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 think it is important to be able to indicate which behaviour you 
require/expect (i.e. whether you want to exclusively 'acquire' the 
message or not). I think the details of what the node you are linking to 
allows with regard to distribution mode should indeed be left 
unspecified at this level (as it is).

I view book IV as defining the minimal requirements beyond the basic 
transport (i.e. book III), allowing semantic interoperability for the 
common, basic messaging patterns without placing unnecessary burdens or 
constraints on implementations.