michi.oshima wrote:
I'm currently exploring 'headers' exchange type. I'd publish a message with
argument table set to 'A' for example, with the intent that consumer with
the matching argument 'A' would receive the message. And those consumers
who do not specify 'A' would not get the message.

I'm finding that a consumer ends up receiving all messages if I pass null as
the value for the 'arguments' parameter.

1. Is this intended? That is, I merely have to specify null for 'arguments'
to receive all messages.
Yes, that is the specified behaviour.
2. Is there any way to prevent a client from subscribing to all messages?
Not directly, but see below.
What I'm trying to achieve is some degree of message privacy. Consumer A
would put the key 'A' to argument to receive all messages meant for A, and
Consumer B would put the key 'B' to argument to receive all messages meant
for B. Consumer A is prevented from receiving messages meant for Consumer
B, simply because he is ignorant of the key 'B'.
So essentially the producer is selecting who is allowed to receive a
message by listing a set of tokens / shared secrets. Right?

I can think of three ways of doing that with RabbitMQ...

1) The publisher sends the message N times to a direct exchange, each
time with an individual security token as the routing key. Consumers
bind to that direct exchange with their token. (You could also just use
the default exchange, if the consumer's queues are named with their
token). The downside of this approach is the cost of having to send
(and for the server to process) the same message multiple times.

2) Write a custom exchange type plug-in. This could work exactly like a
headers exchange but not permit empty bindings. Or it could work more
like a direct exchange, with the producer perhaps listing the tokens in
the message's routing key, comma-separated.

3) Write a proxy that prevents empty bindings.



Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 17 | next ›
Discussion Overview
grouprabbitmq-discuss @
postedNov 8, '10 at 5:34p
activeNov 18, '10 at 6:44p



site design / logo © 2022 Grokbase