[rabbitmq-discuss] Newbie question: How to listen for a certain message content ?

[David Wragg]

Hi Frank,

Frank Gönninger <frank.goenninger at consequor.de> writes:
> Hi all,
>
> being an old Tibco "user" (Tibco Rendezvous) I am looking for a way to
> listen for a "subject" while not having to create separate queues for
> each subject.
>
> I have event messages where I need to have always the same event
> message structure and have different event classes. Is there a way to
> not have queues like
>
> event.application.start
> event.application.abort
> event.application.shutdown
> event.application.terminated
>
> etc et  but rather
>
> have one queue
>
> events
>
> with subjects
>
> application.start etc being part of the message...
>
> I only want my consumer to be awakened when the "right" message is
> arriving ... Yeah, pubsub is it, but how to do this with RabbitMQ ?

The short answer is: using routing keys and a direct or topic exchange.

You ask about how to do this with only a single queue.  With AMQP, You
will need one queue for each consumer, because queues are explicit,
unlike in tibrv.  However, you don't need an exchange per subject.

One way to think of it, from a tibrv point of view, is that AMQP allows
many distinct subject namespaces, which are called exchanges.

So your application could work as follows:

- Declare a single direct exchange, which you might call "events"

- A publishing component publishes to the "events" exchange specifying a
  routing key, which might be "application.start", "application.stop",
  etc.  The routing key accompanies the message on its journey from the
  publisher to consumers.

- A consuming component declares a queue, and binds it to the exchange,
  with the binding key to specify which event type it is interested in.
  With a direct exchange, messages will be delivered to the consumer
  when its binding key matches the routing key under which the message
  was published.  You can bind the queue multiple times, with different
  binding keys, to subscribe to multiple event types.

The need to have each consumer declare a queue might seem like
unnecessary work.  But it is quite straightforward: If you declare with
an unspecified (i.e. empty) name, the server will automatically give the
queue a unique name.  And you can specify the "exclusive" flag for the
queue, so that it will automatically be deleted (along with its
bindings) when you close the connection.

By using a topic exchange, you can also reproduce the hierarchical
nature of tibrv subjects.  For example, if you declare "events" as a
topic exchange, a consumer could bind with a binding key like
"application.*" to subscribe to all application events.

David

-- 
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware