[rabbitmq-discuss] Naive Question

[Bell, Paul M.]

Most kind of you, Jerry. I will check it out tomorrow on home desktop (writing now from phone).

Thanks.

-Paul

On Feb 10, 2012, at 9:28 PM, "Jerry Kuch" <jerryk at vmware.com> wrote:

> Hi, Paul.
> 
> From what I understand of your application this sounds like the right idea.
> Also, a shortcut that may be suitable for you, if you don't want fancy topic routing,
> might be to use the AMQP "default exchange" which will exist by default in any
> vhost.
> 
> The default exchange's name is just the empty string, "".  It's automatically
> bound to any queue you create, with a binding key equal to the name of the queue.
> 
> If you activate the rabbitmq visualiser plugin and browse around you can get a
> nice, interactive view of your queues and exchanges and the bindings between them.
> 
> On my own broker I just created queues called "HB" and "MGMT", and no exchanges, 
> and no bindings.  The attached screenshot shows those queues as the labeled
> rectangles, the bindings as the arrows (if you mouse over one, the routing 
> key will be displayed), and the default exchange as the unlabeled circle at
> the base of the binding arrows (recall it's name is ""; had it a non-empty name,
> you'd see that).
> 
> To publish to the queues I would just publish to an exchange called "", with 
> routing key set to either "MGMT" or "HB".
> 
> For a scenario like yours this might make a nice short cut.
> 
> Best regards,
> Jerry
> 
> ----- Original Message -----
> From: "Paul M. Bell" <pbell at syncsort.com>
> To: "Jerry Kuch" <jerryk at vmware.com>
> Cc: "RabbitMQ List" <rabbitmq-discuss at lists.rabbitmq.com>
> Sent: Friday, February 10, 2012 5:53:44 PM
> Subject: Re: [rabbitmq-discuss] Naive Question
> 
> Hi Jerry,
> 
> Yeah, I think that makes sense.
> 
> Could your two queue be characterized like this:
> 
> 1. Monitor creates the HB queue. With binding key "HB," consumer binds this queue to the exchange. Monitor writes to exchange with routing-key "HB."
> 
> 2. Producer creates the MGMT queue. With binding key "MGMT," monitor binds this queue to exchange. Producer writes to exchange with routing-key "MGMT."
> 
> As always, thank you.
> 
> -Paul
> 
> On Feb 10, 2012, at 8:15 PM, "Jerry Kuch" <jerryk at vmware.com> wrote:
> 
>> Hi, Paul:
>> 
>> Nope:  Redeclarations of a queue with the same name and properties, within a
>> vhost, are idempotent.  Redeclaring the thing before you start using it is
>> a fairly common idiom.  If the resource didn't exist, then it's created;
>> otherwise you've verified its existence.
>> 
>> Redeclaring a queue with a given name with different properties fails, so you
>> can't accidentally vandalize some existing piece of messaging fabric that
>> somebody else might be using.
>> 
>> On point b:  producers publish messages to *exchanges*, not to queues.
>> Which queues, if any, the messages end up in depends on how queues
>> are bound to the exchange in question, and the properties of the message.
>> 
>> With regard to your specific scenario with MGMT and HB messages, are you
>> sure you want them in the same queue?  It's not really possible in any
>> graceful way for a consumer to selectively read some but not other messages
>> from a queue unless one does something obnoxious like basic.get-ing and then
>> rejecting the messages you weren't interested in so that they're requeued.
>> 
>> From what I understand of the design you're sketching, you may want two
>> queues, one from which the monitor reads MGMT messages and one from which 
>> something else reads HB messages.  You could imagine binding both of those
>> queues to a topic exchange and have your producer use routing keys to land
>> your messages in the desired place.
>> 
>> Make sense?
>> 
>> Best regards,
>> Jerry
>> 
>> ----- Original Message -----
>> From: "Paul M. Bell" <pbell at syncsort.com>
>> To: "RabbitMQ List" <rabbitmq-discuss at lists.rabbitmq.com>
>> Sent: Friday, February 10, 2012 3:36:47 PM
>> Subject: [rabbitmq-discuss] Naive Question
>> 
>> All,
>> 
>> Hi again.
>> 
>> Only after trying to think through a real world scenario did I realize that my grasp of certain fundamental AMQP concepts is tenuous.
>> 
>> Specifically, given a producer and a consumer, is the normative behavior for only *one* of them to declare (create?) the queue over which they communicate? As I look over the examples that I've "written" ("copied" would be more accurate), I see my producer doing this:
>> 
>> 
>> RabbitAdmin admin = new RabbitAdmin(rabbitTemplate.getConnectionFactory());
>> Exchange ex = new FanoutExchange(routingKey, true, false);
>> admin.declareExchange(ex);
>> admin.declareQueue(new Queue(this.queueName));
>> 
>> 
>> And I see my consumer doing this:
>> 
>> 
>> ConsumerSimpleMessageListenerContainer container = new ConsumerSimpleMessageListenerContainer();
>> container.setConnectionFactory(connectionFactory());
>> container.setQueueNames(this.queueName);
>> container.setConcurrentConsumers(this.onOfConsumer);
>> container.setMessageListener(new MessageListenerAdapter(new ConsumerHandler(), new SimpleMessageConverter()));
>> container.startConsumers();
>> 
>> 
>> What would happen if each declared a queue of the same name and type - would that give rise to two distinct queues, leaving the producer and consumer unable to communicate?
>> 
>> If it's normative for only one party to create the queue and the other to bind to it, what will happen if, when I try to bind to the queue, it doesn't yet exist?
>> 
>> Here's what I am trying to get to (I assume it requires a topic exchange):
>> 
>> a. a queue that holds two different message types, call them "MGMT" and "HB."
>> b. a producer writes MGMT messages to this queue
>> c. something called a "monitor" writes HB messages to this queue
>> d. consumer reads HB messages from this queue
>> e. monitor reads MGMT messages from this queue
>> 
>> Schematically I think it looks like this:
>> 
>> Producer(MGMT) -> monitor
>> Monitor(HB)    -> consumer
>> 
>> How would I define these relationships via RabbitMQ? Who does what to whom?! I suspect it's simple, but after two solid weeks of 10 hour days, I am fried.
>> 
>> Thank you for your help.
>> 
>> -Paul
>> 
>> PS: What follows is not an attempt to curry favor - but this is a really fine list; folks are friendly, knowledgeable, and eager to help. I really appreciate it.
>> 
>> 
>> 
>> 
>> 
>> ATTENTION: -----
>> 
>> The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other  confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> <Screen Shot 2012-02-10 at 6.16.55 PM.png>