[rabbitmq-discuss] Writing to the mnesia table rabbit_queue, bad idea?

Matthew Sackman matthew at rabbitmq.com
Fri May 13 13:10:36 BST 2011

On Fri, May 13, 2011 at 10:58:34AM +0100, Simon MacMullen wrote:
> Depends how you define "bad idea". In terms of today's
> implementation you should be fine, as long as you don't expect (for
> example) to be able to flip the durability field and have that mean
> something.

It's a very bad idea. For one thing, Rabbit assumes that the queue
record is unaltered after the queue has been created. Consequently the
amqqueue_process process takes a copy of the #amqqueue record and holds
it in its state. It never updates it. So if you change the copy in
mnesia, then you subsquently have divergence between the queue process's
copy, and the mnesia copy. This can lead to suprising results.

For example if you issue amqqueue:info on a queue then it'll go through
to the queue and not mnesia. Thus you'll find that results in management
and in rabbitmqctl now don't match.

You then have things like the property that queue redeclaration should
fail if arguments do not match (semantically) the original declaration.
But this only goes as far as mnesia. Consequently, you will have the
queue, if you interrogate it, claiming its arguments are one thing, but
if you try to redeclare the queue with those arguments, you can find
it'll fail because the mnesia copy is different.

Finally, you'll have the fact that if the broker is restarted, you'll
have the queues recovered with their arguments taken from mnesia. So
suddenly on startup, you'll have queues being restarted with different
arguments from that which they were last running with.


More information about the rabbitmq-discuss mailing list