[rabbitmq-discuss] request for help!

[Martin Sustrik]

Robert Godfrey wrote:

>     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.

Martin