openstack team mailing list archive

[Russell Bryant <rbryant@xxxxxxxxxx>]

On 05/08/2012 05:59 PM, Doug Hellmann wrote:
>     Here is a relevant section pulled out of the amqp 0-9-1 spec:
> 
>        3.1.3.3 The Topic Exchange Type
> 
>        The topic exchange type works as follows:
> 
>            1. A message queue binds to the exchange using a routing
>               pattern, P.
>            2. A publisher sends the exchange a message with the routing
>               key R.
>            3. The message is passed to the message queue if R matches P.
> 
>        The routing key used for a topic exchange MUST consist of zero or
>        more words delimited by dots. Each word may contain the letters A-Z
>        and a-z and digits 0-9.
> 
>        The routing pattern follows the same rules as the routing key with
>        the addition that * matches a single word, and # matches zero or
>        more words. Thus the routing pattern *.stock.# matches the routing
>        keys usd.stock and eur.stock.db but not stock.nasdaq.
> 
>     In nova, for a given topic such as 'scheduler', all of the consumers are
>     binding to the same queue on the topic exchange, resulting in
>     round-robin delivery to each of the consumers.  If instead you make a
>     new queue, you can get your own copy of each message.
> 
>     There is an additional benefit of using a topic exchange here.  The
>     topic used for notifications is 'notifications.<priority>'.  That means
>     that when you create your queue, you can set it up to receive all
>     notifications, or only notifications of a certain priority.
> 
> 
> Topic exchanges make a lot of sense for messages that should only be
> consumed once, such as tasks. Notifications are different. Lots of
> different clients might want to know that some event happened in the
> system. The way things are in Nova today, they can't. The first client
> who consumes a notification message will prevent all of the other
> clients from seeing that message at all.

I think you missed my main point, which was that a topic exchange does
not impose a limitation that only one client can consume a given
notification.  That's only true if each client is consuming from the
same queue bound to the exchange.

> I can change Nova's notification system to use a fanout exchange (in
> impl_kombu.py changing the exchange type used by NotifyPublisher), but
> before I submit a patch I want to make sure the current implementation
> using a topic exchange wasn't selected deliberately for some reason. 

I think using a fanout exchange would be a downgrade.  As I mentioned
before, a topic exchange allows you to create a queue to get all
notifications or only notifications of a specific priority.  If the
exchange type is changed to fanout, it's everybody gets everything, and
that's it.

-- 
Russell Bryant