<br><br><div class="gmail_quote">On Tue, May 8, 2012 at 6:04 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 05/08/2012 05:59 PM, Doug Hellmann wrote:<br>
>     Here is a relevant section pulled out of the amqp 0-9-1 spec:<br>
><br>
>        3.1.3.3 The Topic Exchange Type<br>
><br>
>        The topic exchange type works as follows:<br>
><br>
>            1. A message queue binds to the exchange using a routing<br>
>               pattern, P.<br>
>            2. A publisher sends the exchange a message with the routing<br>
>               key R.<br>
>            3. The message is passed to the message queue if R matches P.<br>
><br>
>        The routing key used for a topic exchange MUST consist of zero or<br>
>        more words delimited by dots. Each word may contain the letters A-Z<br>
>        and a-z and digits 0-9.<br>
><br>
>        The routing pattern follows the same rules as the routing key with<br>
>        the addition that * matches a single word, and # matches zero or<br>
>        more words. Thus the routing pattern *.stock.# matches the routing<br>
>        keys usd.stock and eur.stock.db but not stock.nasdaq.<br>
><br>
>     In nova, for a given topic such as 'scheduler', all of the consumers are<br>
>     binding to the same queue on the topic exchange, resulting in<br>
>     round-robin delivery to each of the consumers.  If instead you make a<br>
>     new queue, you can get your own copy of each message.<br>
><br>
>     There is an additional benefit of using a topic exchange here.  The<br>
>     topic used for notifications is 'notifications.<priority>'.  That means<br>
>     that when you create your queue, you can set it up to receive all<br>
>     notifications, or only notifications of a certain priority.<br>
><br>
><br>
> Topic exchanges make a lot of sense for messages that should only be<br>
> consumed once, such as tasks. Notifications are different. Lots of<br>
> different clients might want to know that some event happened in the<br>
> system. The way things are in Nova today, they can't. The first client<br>
> who consumes a notification message will prevent all of the other<br>
> clients from seeing that message at all.<br>
<br>
</div></div>I think you missed my main point, which was that a topic exchange does<br>
not impose a limitation that only one client can consume a given<br>
notification.  That's only true if each client is consuming from the<br>
same queue bound to the exchange.<br></blockquote><div><br></div><div>Yes, that wasn't obvious from any of the kombu documentation I've seen so far. I'll keep looking.</div><div><br></div><div>Thanks,</div><div>
Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> I can change Nova's notification system to use a fanout exchange (in<br>
> impl_kombu.py changing the exchange type used by NotifyPublisher), but<br>
> before I submit a patch I want to make sure the current implementation<br>
> using a topic exchange wasn't selected deliberately for some reason.<br>
<br>
</div>I think using a fanout exchange would be a downgrade.  As I mentioned<br>
before, a topic exchange allows you to create a queue to get all<br>
notifications or only notifications of a specific priority.  If the<br>
exchange type is changed to fanout, it's everybody gets everything, and<br>
that's it.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span></blockquote></div><br>