I am trying to decide if rabbitmq is something that would fit well in our
architecture. I have a question on what is the best way to approach/design
should be used if I wanted to be able to consume messages from multiple
clients.

My use case is basically:

Unlimited number of clients that can publish and subscribe to messages to
their own queues or exchanges.

An admin client that can subscribe or publish on to any queue or exchange.
The admin client would always be connected. I realize that a client can
have access to any queue or exchange but I want to be able to dynamically
bind to new exchanges/queues as they are added by other users so I
can receive all messages.

Is there a good way to do this?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111028/5ad2f3ca/attachment.htm>

Search Discussions

  • Simon MacMullen at Oct 31, 2011 at 11:42 am

    On 28/10/11 20:45, Chris Chiappone wrote:
    I am trying to decide if rabbitmq is something that would fit well in
    our architecture. I have a question on what is the best way to
    approach/design should be used if I wanted to be able to consume
    messages from multiple clients.

    My use case is basically:

    Unlimited number of clients that can publish and subscribe to messages
    to their own queues or exchanges.

    An admin client that can subscribe or publish on to any queue or exchange.
    The admin client would always be connected. I realize that a client can
    have access to any queue or exchange but I want to be able to
    dynamically bind to new exchanges/queues as they are added by other
    users so I can receive all messages.

    Is there a good way to do this?
    The problem with having your admin user subscribe to everything in the
    general case is how it should know that a new exchange has appeared.
    There are some solutions to this but then you have a race between the
    exchange being declared and the admin user binding to it.

    Of course, depending on your topology this may not be a problem - there
    may be a fixed set of exchanges for example.

    If this *is* a problem then maybe the firehose could be what you're
    looking for:

    http://www.rabbitmq.com/firehose.html

    although your admin app would have to unpack the messages it produces
    slightly.

    Cheers, Simon
    --
    Simon MacMullen
    RabbitMQ, VMware
  • Chris Chiappone at Oct 31, 2011 at 4:00 pm
    I had figured that could be the case. I don't think firehose is probably
    the answer for us since I don't want to worry about performance issues. I
    think we can set up exchanges for clients and bind to them before they even
    connect so that may be the way to go. Is there limits to the number of
    exchanges a client can bind to?

    thanks
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111031/abd2f9a3/attachment.htm>
  • Simon MacMullen at Oct 31, 2011 at 4:13 pm

    On 31/10/11 16:00, Chris Chiappone wrote:
    I had figured that could be the case. I don't think firehose is probably
    the answer for us since I don't want to worry about performance issues.
    Hmm, that warning is perhaps rather strongly worded...
    I think we can set up exchanges for clients and bind to them before they
    even connect so that may be the way to go. Is there limits to the number
    of exchanges a client can bind to?
    Well, queues bind to exchanges. But there's no hard limit on that.

    Cheers, Simon

    --
    Simon MacMullen
    RabbitMQ, VMware

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedOct 28, '11 at 7:45p
activeOct 31, '11 at 4:13p
posts4
users2
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase