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

[Ergeerts Glenn]

Hi,

I thought about that option, but I think it is not flexible enough for our application.
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?

I did not know about the option of implementing a custom exchange type.. Is it hard to do?
I don't know if this would be an ideal solution.. it feels strange pulling this application specific logic into the communication infrastructure (so tying our application to RabbitMQ) to me.. ?

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?

Thanks,
Glenn

-----Oorspronkelijk bericht-----
Van: Tony Garnock-Jones [mailto:tonyg at lshift.net] 
Verzonden: donderdag 4 maart 2010 0:20
Aan: Ergeerts Glenn
CC: rabbitmq-discuss at lists.rabbitmq.com
Onderwerp: Re: [rabbitmq-discuss] SimpleRpcServer send generated queue name to client

Hi,

glenner wrote:
> And, more general, is this a valid design using RabbitMQ/AMQP? I'm still new
> to RabbitMQ/AMQP so maybe i overlooked a more approriate way to do this..

It sounds reasonable; but it might be possible to leverage the features
of the RabbitMQ server even more than you have in mind.

For example, could it work to design a topic hierarchy for your system's
events, and then simply use an AMQP topic exchange to broadcast them to
the correct consumers?

The application-level server would then blindly send events, with an
appropriate routing key, to a named exchange it had set up, and the
clients would create private queues (using queueDeclare()) and bind them
(using queueBind()) to the exchange with appropriate binding key for
selecting the subset of events they are interested in. There need then
be no direct communication between the clients and the application-level
server.

You mentioned there were custom filter predicates. These are a potential
missing piece. If the event types don't fit nicely onto the routing keys
usable with topic exchanges, then you will be relying on client-side
filtering, which may or may not be suitable for your application. On the
other hand, if routing keys and a topic exchange get you 99% of the way
there, then the remaining small amount of filtering can easily be done
on the client side. A final option would be to implement a custom
exchange type which is capable of understanding your filter predicates
within the AMQP server itself.

Regards,
  Tony