[rabbitmq-discuss] Problem with multiple subscribers on the same queue

[Ben Hood]

Franck,

On Fri, Aug 28, 2009 at 2:37 AM, Boisson, Franck<Franck.Boisson at mlp.com> wrote:
>> So if that is the case, can't you use a topic exchange to only make
>> exact matches - i.e. when you construct your routing table, you just
>> make sure that you don't have bindings that cause a message to be
>> multicasted to more that one queue? Or as an alternative, since the
>> message type is a discriminating factor, why not make it out to be a
>> first class endpoint and send each different message type directly to
>> a well-known queue whose consumers only process that message type?
>
> Ok but here is something I do not know how to do. How can I make sure
> that I don't have bindings that cause a message to be multicasted to
> more than one queue when I bind a new queue?

You could use read ACLs that only permit certain users to creating
bindings to a certain exchange - this would limit anybody's ability to
multicast messages. But you'd still have to do it manually.

> For you second proposition, I believe you assume that my subscribing
> clients know the exact scope off all my publishers in order to address
> the good one. Isn't it?

Yes.

> Another question I have is: How can I monitor a queue? I would like to
> know when a queue goes down.

You can't via the protocol ATM. Right now you can use the rabbitmqctl
interface.  BQL will be available as a plugin in the next release, but
this just gives you similar semantics to rabbitmqctl.

> For the moment, all my subscribers clients create their own queue when
> they start (let's say subscribe.A#PING for client A and subscribe.B#PING
> for client B) and they give these queue ids to the publishing client.
> After that, nothing is done on these queues but the publishing client is
> watching at them (through a queueDeclare with passive=true) and if a
> queues goes down, the publishing client consider that the subscribing
> client has shutted-down and it clean his internal cache in as a
> consequence.

Yes, this whole area is an issue. The wheels are in motion to
introduce some kind of presence notification, but this requires a lot
more thought and development and hence there's no ETA.

For now what you can do from a sending perspective is to set the
mandatory flag - this will result in a return if the message could not
be routed.

Cheers,

Ben

PS I've looked at the mailman admin to send if there is a pending
request from you, which there isn't. Can you maybe send the rejection
message please?