[rabbitmq-discuss] exchanges and message processing

[Matthias Radestock]

Joe,

Joe Williams wrote:
> This is in relation to a thread I started on the ruby-amqp list:
> 
> http://groups.google.com/group/ruby-amqp/browse_thread/thread/6296567fa545ca8d?hl=en
> 
> 
> My question is regarding exchanges, queues and dealing with messages 
> that I would like to get processed only once. I am sending messages 
> containing json and would like to use a field from the json as the 
> routing key to alleviate needing to do numerous case statements in my 
> code. It seems that fanout and direct exchanges would not work since 
> they have possibility of having messages getting processed more than 
> once by different consumers. The responder on the ruby-amqp list 
> mentioned a shared queue that is in the 091 spec. But this seems to put 
> me back at using a long case statement.
> 
> In an ideal situation I would have multiple consumers (written without 
> epic case statements) and messages that get consumed once and only once.
> 
> Any suggestions on how to go about doing something like this?

The role of exchanges is to route messages to queues. They *all* have 
the possibility of resulting in messages getting routed to multiple 
queues and hence processed by multiple consumers - that's what they are 
there for. Whether that actually happens depends on the bindings that 
have been configured.

For your use case, the following setup should work:
- one direct exchange
- one queue for each of the case branches
- one binding per queue to the direct exchange, with the binding key set 
to the case branch discriminator
- one consumer per queue, handling the messages for one particular 
branch discriminator

In this setup messages will get routed to exactly one consumer, based on 
their routing key. You'd only get duplication if you set up additional 
queues and consumers that bound to the direct exchange with the same 
binding keys.

One possible downside of this setup compared to a single queue is that 
message order is not preserved across queues.


Regards,

Matthias.