[rabbitmq-discuss] Naive Question

[Bell, Paul M.]

Hi Jerry,

OK, I think I understand now.

I think I will have my consumer create the two queues on the fly. These queues ("heartbeat" and "management") need live only for the duration of the long running task. The consumer is the first to know that the task has been accepted for processing, so consumer is a natural place to create the queues.

Again, the scenario is:

1. monitor sends heartbeat messages to the heartbeat queue; consumer receives them. 
2. a producer (in a higher layer) sends management messages to the management queue; monitor receives them.

Given what you said about queue creation idempotency, I trust it can't hurt if the other endpoint also declares the queue. E.g., in case (1) monitor declares the queue; in case (2) both producer and monitor declare the queue (in case (2) the queue was created by an entity that is not involved in the communication, i.e., consumer created it, but it is used by producer and monitor).

But I am uncertain about the "bind" operation. The sense I have is that only a receiver need bind (with a specific binding key) the queue to the exchange. Is that right?

Thanks for your help.

Cordially,

Paul

-----Original Message-----
From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Bell, Paul M.
Sent: Friday, February 10, 2012 8:54 PM
To: Jerry Kuch
Cc: RabbitMQ List
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
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss