Kinda! The queue has a name, but that name has no bearing on the set of messages received.
If you create a queue called "MyCustomNotificationQueue", you can bind that to the "notifications" exchange using the "notifications.info" routing key. (I'm guessing some of the names here.. I know AMQP, and not the specific naming nova uses!) Nova just happens to use the same queue name and routing key. I believe this is causing the confusion. Does this make sense? Anyway - The RabbitMQ docs probably explain it better than I.. http://www.rabbitmq.com/tutorials/tutorial-five-python.html Thanks, Kiall On Wed, May 9, 2012 at 11:30 AM, Day, Phil <philip....@hp.com> wrote: > OK, get that so far – so both consumers need to declare and use the same > exchange.**** > > ** ** > > But If I understand the next step right, to get multiple consumers of > info notification messages they would all need to create separate “ > notifications.info” queues into that exchange. And isn’t that exactly > what Nova currently does to create a shared queue ?**** > > ** ** > > Phil**** > > ** ** > > *From:* Kiall Mac Innes [mailto:ki...@managedit.ie] > *Sent:* 09 May 2012 10:51 > *To:* Day, Phil > *Cc:* openstack@lists.launchpad.net; Russell Bryant; Doug Hellmann > > *Subject:* Re: [Openstack] [nova] why does notification use a "topic" > exchange instead of "fanout"?**** > > ** ** > > Your own queue listener should attempt to declare the exchange, using the > same settings as Nova does. **** > > If the exchange exists, its a noop. Otherwise it's created for you.**** > > After that, if you start up Nova, it will do the same and reuse your > exchange.**** > > Obviously this works both ways, and either nova or your code can declare > the exchange.**** > > AMQP is designed to be a configuration-less protocol, where resources are > configured by the first consumer attempting to use them.**** > > Thanks, > Kiall**** > > Sent from my phone.**** > > On May 9, 2012 9:52 a.m., "Day, Phil" <philip....@hp.com> wrote:**** > > Hi Doug,**** > > **** > > > 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.**** > > **** > > So just to be clear, if I understand you correctly within the nova > service/rpc abstraction layers the code is set up so that all services do > bind to the same queue, and hence we get the round-robin delivery.**** > > But, if someone wanted to write a separate notification consumer so that > they didn’t block anyone else from seeing the same messages then they (the > consumer) should create a new queue on the existing topic exchange.**** > > **** > > Is that correct – and is there any worked example of doing this ?**** > > **** > > I thought within the nova code both the exchange and topic queues were set > up by the consumer (so for example all compute_managers try to create the > “compute” exchange and topic queue, but its only created by the first one > and the others connect to the same queue). In that context I’m finding it > hard to see how to change this model to have multiple “notify.info” topic > queues into the same exchange ?**** > > **** > > Cheers,**** > > Phil**** > > **** > > **** > > **** > > **** > > *From:* openstack-bounces+philip.day=hp....@lists.launchpad.net [mailto: > openstack-bounces+philip.day=hp....@lists.launchpad.net] *On Behalf Of *Doug > Hellmann > *Sent:* 08 May 2012 23:34 > *To:* Russell Bryant > *Cc:* openstack@lists.launchpad.net > *Subject:* Re: [Openstack] [nova] why does notification use a "topic" > exchange instead of "fanout"?**** > > **** > > **** > > On Tue, May 8, 2012 at 6:04 PM, Russell Bryant <rbry...@redhat.com> wrote: > **** > > 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.**** > > **** > > Yes, that wasn't obvious from any of the kombu documentation I've seen so > far. I'll keep looking.**** > > **** > > Thanks,**** > > Doug**** > > **** > > > > 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**** > > **** > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp**** >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
