[rabbitmq-discuss] queue/exchange creation/deletion replication serialization

[Matthias Radestock]

Ray,

On 20/11/12 16:39, Ray Pekowski wrote:
> Is it known that the dynamic creation and deletion of queues and
> exchanges is costly in a clustered environment?

Yes. Though not *just* in a clustered environment. It is orders of 
magnitude slower than, say, publishing or consuming a message. For that 
reason, usage that results in "one exchange/queue per message" should 
very much be considered an anti-pattern.

In case of RPC, the typical approach - as shown in our tutorials at See 
http://www.rabbitmq.com/tutorials/tutorial-six-python.html - is to 
create one reply queue per caller, and use that for all rpc calls by 
that caller. And there is no need to create an exchange - just use the 
default exchange.

If a logical caller exists across multiple successive OS processes, then 
instead of declaring the reply queue as 'exclusive' (which causes it to 
be deleted on connection/application termination), one can employ queue 
leases to bound the life time. If it is convenient, one can still 
declare the queues at every call - that is cheap if the queue already 
exists.

> Is it known that the replication of queues and exchanges in a cluster
> environment is a serialization point that bottlenecks RabbitMQ
> scalability for this dynamic queue/exchange use pattern?

A fair amount of synchronisation/serialisation between nodes is 
inevitable for AMQP queue/exchange declaration since the broker needs to 
ensure that one cannot create two different queues/exchanges with the 
same name when concurrently connecting to two nodes in a cluster.


Regards,

Matthias.