[rabbitmq-discuss] SimpleRpcServer send generated queue name to client

[Matthias Radestock]

Glenn,

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 
filtering predicates.

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 
http://www.lshift.net/blog/2010/01/22/plugin-exchange-types-for-rabbitmq 
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.


Regards,

Matthias.