Hello All,

A few miscellaneous questions about RabbitMQ.....

1. Is it possible for a consumer to consume specific messages from a queue, e.g., one that contains a specific value (like a unique "request ID" that is part of each message)?

2. Is it possible for a consumer to "run a queue," e.g., visit each message in the queue without removing it?

3. Perhaps related to (1): does Rabbit support a kind of queue "peek" logic in the manner of Queue objects in C# and elsewhere? Peek allows one to obtain the queue head but leave it in place. (I know from previous threads on this list that message will remain in Q until expressly ack-ed, so maybe that's the answer.....)

Behind my questions is something I learned re Microsoft's Azure design. Its message queues can be manipulated via RESTful URIs. Consequently, the contents of an Azure queue can be queried, just as one might query data in the persistence layer.

I am not sure if we can do this via RabbitMQ. But I would like it if the queues could be "first-class citizens" in this regard. After all, they do contain and reflect useful state about the application. Suppose I have a message sitting in the queue that is waiting to be "dispatched" by a consumer. Now user wants to suspend the message (actually, suspend the task that will be dispatched in response to this message) so that it is no longer eligible for dispatch. How might I approach this with RabbitMQ? (I recall from an earlier thread that, because you can't modify a message in place, you'd have to read the message, update it (set "suspend") and then reinsert it into queue).

As always, thanks for your help.

-Paul



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.

Search Discussions

  • Emile Joubert at Feb 6, 2012 at 1:46 pm
    Hi Paul,
    On 06/02/12 12:37, Bell, Paul M. wrote:
    1. Is it possible for a consumer to consume specific messages from a
    queue, e.g., one that contains a specific value (like a unique
    "request ID" that is part of each message)?
    No, but if you are trying to match up requests with replies then
    consider making use of a dedicated reply queue, in the way RPC does. The
    6th tutorial explains in greater detail:
    http://www.rabbitmq.com/tutorials/tutorial-six-java.html
    2. Is it possible for a consumer to "run a queue," e.g., visit each
    message in the queue without removing it?
    In theory a consumer could fetch many messages without acknowledgement,
    acknowledge only those that match a filter and requeue the remainder.
    Treating a queue like this strongly discouraged. The specification says
    of basic.reject:

    "The client MUST NOT use this method as a means of selecting messages to
    process. "

    If you require random access to messages then consider using a database,
    or redesigning the message flow in such a way that consumers are able to
    process all messages at the head of a queue.
    3. Perhaps related to (1): does Rabbit support a kind of queue "peek"
    logic in the manner of Queue objects in C# and elsewhere? Peek allows
    one to obtain the queue head but leave it in place. (I know from
    previous threads on this list that message will remain in Q until
    expressly ack-ed, so maybe that's the answer.....)
    A consumer can fetch and requeue a message from a queue, but (unless
    there are other consumers consuming from the same queue) it will not
    make any progress this way. The reason is that the consumer will see the
    same message over and over.
    Behind my questions is something I learned re Microsoft's Azure
    design. Its message queues can be manipulated via RESTful URIs.
    Consequently, the contents of an Azure queue can be queried, just as
    one might query data in the persistence layer.
    Data structures that can be browsed and manipulated in this way are not
    strictly speaking queues. For performance reasons the internal data
    structures in RabbitMQ have queues that do not permit random data access
    patterns.




    -Emile
  • Bell, Paul M. at Feb 7, 2012 at 4:28 pm
    Merci beaucoup, Emile, for another very helpful reply. I appreciate it.

    It seems that I may have a "square peg, round hole" problem in the way I am trying to use RabbitMQ. Perhaps it's not the right tool for the job. That said, I think it has much to offer and I am championing its use in-house.

    Your mention of database in the context of "random access" to a queue leads me to the following questions (and here I am in way over my head): I recall that Rabbit supports different types of queue backing storage by means of "extensions." Would it be possible via such an extension to back the queue with, say, SQL storage? And might this allow, through standard SQL access patterns, random access to the queue?

    Thanks again.

    -Paul

    -----Original Message-----
    From: Emile Joubert [mailto:emile at rabbitmq.com]
    Sent: Monday, February 06, 2012 8:46 AM
    To: Bell, Paul M.
    Cc: RabbitMQ List
    Subject: Re: [rabbitmq-discuss] Queue Look-ahead, et alia

    Hi Paul,
    On 06/02/12 12:37, Bell, Paul M. wrote:
    1. Is it possible for a consumer to consume specific messages from a
    queue, e.g., one that contains a specific value (like a unique
    "request ID" that is part of each message)?
    No, but if you are trying to match up requests with replies then
    consider making use of a dedicated reply queue, in the way RPC does. The
    6th tutorial explains in greater detail:
    http://www.rabbitmq.com/tutorials/tutorial-six-java.html
    2. Is it possible for a consumer to "run a queue," e.g., visit each
    message in the queue without removing it?
    In theory a consumer could fetch many messages without acknowledgement,
    acknowledge only those that match a filter and requeue the remainder.
    Treating a queue like this strongly discouraged. The specification says
    of basic.reject:

    "The client MUST NOT use this method as a means of selecting messages to
    process. "

    If you require random access to messages then consider using a database,
    or redesigning the message flow in such a way that consumers are able to
    process all messages at the head of a queue.
    3. Perhaps related to (1): does Rabbit support a kind of queue "peek"
    logic in the manner of Queue objects in C# and elsewhere? Peek allows
    one to obtain the queue head but leave it in place. (I know from
    previous threads on this list that message will remain in Q until
    expressly ack-ed, so maybe that's the answer.....)
    A consumer can fetch and requeue a message from a queue, but (unless
    there are other consumers consuming from the same queue) it will not
    make any progress this way. The reason is that the consumer will see the
    same message over and over.
    Behind my questions is something I learned re Microsoft's Azure
    design. Its message queues can be manipulated via RESTful URIs.
    Consequently, the contents of an Azure queue can be queried, just as
    one might query data in the persistence layer.
    Data structures that can be browsed and manipulated in this way are not
    strictly speaking queues. For performance reasons the internal data
    structures in RabbitMQ have queues that do not permit random data access
    patterns.




    -Emile



    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.
  • Jerry Kuch at Feb 7, 2012 at 4:37 pm
    Hi, Paul.

    It is in fact possible to write alternate storage backends
    for queue contents, but it's a non-trivial amount of work
    and may ultimately give you something you don't want.

    The current persister used by Rabbit is explicitly quite
    tuned to messaging use cases; other data stores may cater
    to quite different workloads and give you performance, or
    perhaps even correctness, situations you won't enjoy.

    A discussion of some of the issues can be found here:

    http://www.rabbitmq.com/blog/2011/01/20/rabbitmq-backing-stores-databases-and-disks/

    Best regards,
    Jerry

    ----- Original Message -----
    From: "Paul M. Bell" <pbell at syncsort.com>
    To: "Emile Joubert" <emile at rabbitmq.com>
    Cc: "RabbitMQ List" <rabbitmq-discuss at lists.rabbitmq.com>
    Sent: Tuesday, February 7, 2012 8:28:35 AM
    Subject: Re: [rabbitmq-discuss] Queue Look-ahead, et alia

    Merci beaucoup, Emile, for another very helpful reply. I appreciate it.

    It seems that I may have a "square peg, round hole" problem in the way I am trying to use RabbitMQ. Perhaps it's not the right tool for the job. That said, I think it has much to offer and I am championing its use in-house.

    Your mention of database in the context of "random access" to a queue leads me to the following questions (and here I am in way over my head): I recall that Rabbit supports different types of queue backing storage by means of "extensions." Would it be possible via such an extension to back the queue with, say, SQL storage? And might this allow, through standard SQL access patterns, random access to the queue?

    Thanks again.

    -Paul

    -----Original Message-----
    From: Emile Joubert [mailto:emile at rabbitmq.com]
    Sent: Monday, February 06, 2012 8:46 AM
    To: Bell, Paul M.
    Cc: RabbitMQ List
    Subject: Re: [rabbitmq-discuss] Queue Look-ahead, et alia

    Hi Paul,
    On 06/02/12 12:37, Bell, Paul M. wrote:
    1. Is it possible for a consumer to consume specific messages from a
    queue, e.g., one that contains a specific value (like a unique
    "request ID" that is part of each message)?
    No, but if you are trying to match up requests with replies then
    consider making use of a dedicated reply queue, in the way RPC does. The
    6th tutorial explains in greater detail:
    http://www.rabbitmq.com/tutorials/tutorial-six-java.html
    2. Is it possible for a consumer to "run a queue," e.g., visit each
    message in the queue without removing it?
    In theory a consumer could fetch many messages without acknowledgement,
    acknowledge only those that match a filter and requeue the remainder.
    Treating a queue like this strongly discouraged. The specification says
    of basic.reject:

    "The client MUST NOT use this method as a means of selecting messages to
    process. "

    If you require random access to messages then consider using a database,
    or redesigning the message flow in such a way that consumers are able to
    process all messages at the head of a queue.
    3. Perhaps related to (1): does Rabbit support a kind of queue "peek"
    logic in the manner of Queue objects in C# and elsewhere? Peek allows
    one to obtain the queue head but leave it in place. (I know from
    previous threads on this list that message will remain in Q until
    expressly ack-ed, so maybe that's the answer.....)
    A consumer can fetch and requeue a message from a queue, but (unless
    there are other consumers consuming from the same queue) it will not
    make any progress this way. The reason is that the consumer will see the
    same message over and over.
    Behind my questions is something I learned re Microsoft's Azure
    design. Its message queues can be manipulated via RESTful URIs.
    Consequently, the contents of an Azure queue can be queried, just as
    one might query data in the persistence layer.
    Data structures that can be browsed and manipulated in this way are not
    strictly speaking queues. For performance reasons the internal data
    structures in RabbitMQ have queues that do not permit random data access
    patterns.




    -Emile



    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
  • Bell, Paul M. at Feb 7, 2012 at 6:23 pm
    Hi Jerry,

    Thank you for the reply.

    I hear you. I had a feeling that this might be a lot of work, but hadn't considered the performance/correctness possibilities you touch on. Non-enjoyment is non-good!

    I will check out the link.

    -Paul

    -----Original Message-----
    From: Jerry Kuch [mailto:jerryk at vmware.com]
    Sent: Tuesday, February 07, 2012 11:38 AM
    To: Bell, Paul M.
    Cc: RabbitMQ List; Emile Joubert
    Subject: Re: [rabbitmq-discuss] Queue Look-ahead, et alia

    Hi, Paul.

    It is in fact possible to write alternate storage backends
    for queue contents, but it's a non-trivial amount of work
    and may ultimately give you something you don't want.

    The current persister used by Rabbit is explicitly quite
    tuned to messaging use cases; other data stores may cater
    to quite different workloads and give you performance, or
    perhaps even correctness, situations you won't enjoy.

    A discussion of some of the issues can be found here:

    http://www.rabbitmq.com/blog/2011/01/20/rabbitmq-backing-stores-databases-and-disks/

    Best regards,
    Jerry

    ----- Original Message -----
    From: "Paul M. Bell" <pbell at syncsort.com>
    To: "Emile Joubert" <emile at rabbitmq.com>
    Cc: "RabbitMQ List" <rabbitmq-discuss at lists.rabbitmq.com>
    Sent: Tuesday, February 7, 2012 8:28:35 AM
    Subject: Re: [rabbitmq-discuss] Queue Look-ahead, et alia

    Merci beaucoup, Emile, for another very helpful reply. I appreciate it.

    It seems that I may have a "square peg, round hole" problem in the way I am trying to use RabbitMQ. Perhaps it's not the right tool for the job. That said, I think it has much to offer and I am championing its use in-house.

    Your mention of database in the context of "random access" to a queue leads me to the following questions (and here I am in way over my head): I recall that Rabbit supports different types of queue backing storage by means of "extensions." Would it be possible via such an extension to back the queue with, say, SQL storage? And might this allow, through standard SQL access patterns, random access to the queue?

    Thanks again.

    -Paul

    -----Original Message-----
    From: Emile Joubert [mailto:emile at rabbitmq.com]
    Sent: Monday, February 06, 2012 8:46 AM
    To: Bell, Paul M.
    Cc: RabbitMQ List
    Subject: Re: [rabbitmq-discuss] Queue Look-ahead, et alia

    Hi Paul,
    On 06/02/12 12:37, Bell, Paul M. wrote:
    1. Is it possible for a consumer to consume specific messages from a
    queue, e.g., one that contains a specific value (like a unique
    "request ID" that is part of each message)?
    No, but if you are trying to match up requests with replies then
    consider making use of a dedicated reply queue, in the way RPC does. The
    6th tutorial explains in greater detail:
    http://www.rabbitmq.com/tutorials/tutorial-six-java.html
    2. Is it possible for a consumer to "run a queue," e.g., visit each
    message in the queue without removing it?
    In theory a consumer could fetch many messages without acknowledgement,
    acknowledge only those that match a filter and requeue the remainder.
    Treating a queue like this strongly discouraged. The specification says
    of basic.reject:

    "The client MUST NOT use this method as a means of selecting messages to
    process. "

    If you require random access to messages then consider using a database,
    or redesigning the message flow in such a way that consumers are able to
    process all messages at the head of a queue.
    3. Perhaps related to (1): does Rabbit support a kind of queue "peek"
    logic in the manner of Queue objects in C# and elsewhere? Peek allows
    one to obtain the queue head but leave it in place. (I know from
    previous threads on this list that message will remain in Q until
    expressly ack-ed, so maybe that's the answer.....)
    A consumer can fetch and requeue a message from a queue, but (unless
    there are other consumers consuming from the same queue) it will not
    make any progress this way. The reason is that the consumer will see the
    same message over and over.
    Behind my questions is something I learned re Microsoft's Azure
    design. Its message queues can be manipulated via RESTful URIs.
    Consequently, the contents of an Azure queue can be queried, just as
    one might query data in the persistence layer.
    Data structures that can be browsed and manipulated in this way are not
    strictly speaking queues. For performance reasons the internal data
    structures in RabbitMQ have queues that do not permit random data access
    patterns.




    -Emile



    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
  • Jerry Kuch at Feb 7, 2012 at 6:25 pm
    Hi, Paul:

    Definitely do, and then we can talk more on the list about
    your actual needs. Sometimes a hybrid solution, with Rabbit
    doing the things its good at, and something else integrated
    sensibly alongside in your application, is the best way to go...

    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>, "Emile Joubert" <emile at rabbitmq.com>
    Sent: Tuesday, February 7, 2012 10:23:59 AM
    Subject: RE: [rabbitmq-discuss] Queue Look-ahead, et alia

    Hi Jerry,

    Thank you for the reply.

    I hear you. I had a feeling that this might be a lot of work, but hadn't considered the performance/correctness possibilities you touch on. Non-enjoyment is non-good!

    I will check out the link.

    -Paul

    -----Original Message-----
    From: Jerry Kuch [mailto:jerryk at vmware.com]
    Sent: Tuesday, February 07, 2012 11:38 AM
    To: Bell, Paul M.
    Cc: RabbitMQ List; Emile Joubert
    Subject: Re: [rabbitmq-discuss] Queue Look-ahead, et alia

    Hi, Paul.

    It is in fact possible to write alternate storage backends
    for queue contents, but it's a non-trivial amount of work
    and may ultimately give you something you don't want.

    The current persister used by Rabbit is explicitly quite
    tuned to messaging use cases; other data stores may cater
    to quite different workloads and give you performance, or
    perhaps even correctness, situations you won't enjoy.

    A discussion of some of the issues can be found here:

    http://www.rabbitmq.com/blog/2011/01/20/rabbitmq-backing-stores-databases-and-disks/

    Best regards,
    Jerry

    ----- Original Message -----
    From: "Paul M. Bell" <pbell at syncsort.com>
    To: "Emile Joubert" <emile at rabbitmq.com>
    Cc: "RabbitMQ List" <rabbitmq-discuss at lists.rabbitmq.com>
    Sent: Tuesday, February 7, 2012 8:28:35 AM
    Subject: Re: [rabbitmq-discuss] Queue Look-ahead, et alia

    Merci beaucoup, Emile, for another very helpful reply. I appreciate it.

    It seems that I may have a "square peg, round hole" problem in the way I am trying to use RabbitMQ. Perhaps it's not the right tool for the job. That said, I think it has much to offer and I am championing its use in-house.

    Your mention of database in the context of "random access" to a queue leads me to the following questions (and here I am in way over my head): I recall that Rabbit supports different types of queue backing storage by means of "extensions." Would it be possible via such an extension to back the queue with, say, SQL storage? And might this allow, through standard SQL access patterns, random access to the queue?

    Thanks again.

    -Paul

    -----Original Message-----
    From: Emile Joubert [mailto:emile at rabbitmq.com]
    Sent: Monday, February 06, 2012 8:46 AM
    To: Bell, Paul M.
    Cc: RabbitMQ List
    Subject: Re: [rabbitmq-discuss] Queue Look-ahead, et alia

    Hi Paul,
    On 06/02/12 12:37, Bell, Paul M. wrote:
    1. Is it possible for a consumer to consume specific messages from a
    queue, e.g., one that contains a specific value (like a unique
    "request ID" that is part of each message)?
    No, but if you are trying to match up requests with replies then
    consider making use of a dedicated reply queue, in the way RPC does. The
    6th tutorial explains in greater detail:
    http://www.rabbitmq.com/tutorials/tutorial-six-java.html
    2. Is it possible for a consumer to "run a queue," e.g., visit each
    message in the queue without removing it?
    In theory a consumer could fetch many messages without acknowledgement,
    acknowledge only those that match a filter and requeue the remainder.
    Treating a queue like this strongly discouraged. The specification says
    of basic.reject:

    "The client MUST NOT use this method as a means of selecting messages to
    process. "

    If you require random access to messages then consider using a database,
    or redesigning the message flow in such a way that consumers are able to
    process all messages at the head of a queue.
    3. Perhaps related to (1): does Rabbit support a kind of queue "peek"
    logic in the manner of Queue objects in C# and elsewhere? Peek allows
    one to obtain the queue head but leave it in place. (I know from
    previous threads on this list that message will remain in Q until
    expressly ack-ed, so maybe that's the answer.....)
    A consumer can fetch and requeue a message from a queue, but (unless
    there are other consumers consuming from the same queue) it will not
    make any progress this way. The reason is that the consumer will see the
    same message over and over.
    Behind my questions is something I learned re Microsoft's Azure
    design. Its message queues can be manipulated via RESTful URIs.
    Consequently, the contents of an Azure queue can be queried, just as
    one might query data in the persistence layer.
    Data structures that can be browsed and manipulated in this way are not
    strictly speaking queues. For performance reasons the internal data
    structures in RabbitMQ have queues that do not permit random data access
    patterns.




    -Emile



    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
  • Bell, Paul M. at Feb 10, 2012 at 11:36 pm
    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.
  • Jerry Kuch at Feb 11, 2012 at 1:15 am
    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.
  • Bell, Paul M. at Feb 11, 2012 at 1:53 am
    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" 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
  • Jerry Kuch at Feb 11, 2012 at 2:28 am
    Hi, Paul.
  • Bell, Paul M. at Feb 11, 2012 at 2:48 am
    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" 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" 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>
  • Bell, Paul M. at Feb 11, 2012 at 6:50 pm
    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" 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
  • Jerry Kuch at Feb 12, 2012 at 5:28 am
    Hi, Paul:

    Your understanding of idempotency in this case is correct. Anybody
    trying to declare a queue or exchange of a given name that collides
    with an existing one, succeeds trivially as long as they've not asked
    for any properties different from those of the existing one.

    Not that if you're publishing to an exchange that's not bound to any
    queues, there's nowhere for the messages to actually go. You may
    want to review the "mandatory" and "immediate" flags that you can use
    when publishing messages. The mandatory flag tells the server that if
    it wasn't able to place the message in any queues (e.g. none were bound
    suitably), it should let the publisher know rather than silently dropping
    the message, its default behavior. Think of it along the lines of "Put
    this message in at least one queue, and if you can't sent it back to me."
    With the immediate flag, you are essentially asking the message to be
    delievered to a consumer immediately if one is connected and able to take
    delivery of the message, otherwise don't bother requeuing it for later
    delivery.

    You may want to keep those flags in mind if you're working in cases
    where consumers' queues may not be ready yet.

    Regarding bindings... A queue must be bound to an exchange in order to
    receive any messages. Recall that producers publish *to an exchange*,
    and the message so published then finds its way into queues based on
    1) its properties and 2) what bindings, if any, exist between the
    exchange and queues. Its those connections, from exchanges to queues,
    that you create (unless you're freeloading on the trivial connections
    that automatically existing between the default exchange and any
    queue, at the moment of that queue's birth).

    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: Saturday, February 11, 2012 10:50:15 AM
    Subject: RE: [rabbitmq-discuss] Naive Question

    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" 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedFeb 6, '12 at 12:37p
activeFeb 12, '12 at 5:28a
posts13
users3
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase