[rabbitmq-discuss] SimpleRpcServer send generated queue name to client
matthias at lshift.net
Tue Mar 23 13:57:03 GMT 2010
Ergeerts Glenn wrote:
> Like you said the custom filer predicates are very flexible. It could
> be possible to map them to routing keys and use client side
> filtering as you said, but for security reasons I want control
> exactly which client receives which messages. So this rules out
> client side filtering I guess?
Do these security considerations only apply to event types or the event
filtering predicates too?
If the former, you could go for a hybrid solution where the server
publishes events to a direct exchange, with the event type as the
routing key. Each client's queue would then be bound to that exchange
with binding keys for each of the event types the client is interested
in. And client-side filtering would take care of the more complex
The creation/deletion of the client queues could be left up to the
clients, but the access to the exchange could be restricted to the
server, with all bindings of client queues to the exchange being
established by that server.
> I did not know about the option of implementing a custom exchange
> type.. Is it hard to do?
It's fairly straightforward - if you know a bit about Erlang and the
rabbit internals ;) See
for an example.
> it feels strange pulling this application specific logic
> into the communication infrastructure (so tying our application to
> RabbitMQ) to me.. ?
The standard, but less efficient, approach to implementing arbitrary
complex routing logic is to introduce a routing client. That is an
ordinary AMQP client which
a) consumes messages from, say, a single queue bound to a fanout
exchange to which producer send all publishes,
b) applies the necessary routing logic to compute a set of queues to
send the message to,
c) publishes copies of the message to the default exchange - one copy
per queue it needs routing too.
That's the basic setup, which can be suitably embellished by, say,
consuming from multiple exchanges/queues, and publishing to exchanges
other than the default exchange. Plus of course you need logic to deal
with subscription management.
> What would be the disadvantages of doing it with the multiple queues
> as first suggested? Is it performance related? Would it make a big
> difference using a topic exchange compared to for example 20 queues +
> subscriptions? Are there other disadvantages?
You end up with one queue per client in all solutions proposed so far.
But there is still a performance advantage of getting rabbit to do as
much of the routing as possible. That's what it's designed to do, and it
(mostly) does it very efficiently. For example, if the same message
needs to go to 10 different queues, doing the routing in application
code results in ten separate copies of the message, all getting routed
separately, whereas if rabbit does the routing there will be just one
copy of the message and the distribution of that message to individual
queues is done very efficiently.
More information about the rabbitmq-discuss