[rabbitmq-discuss] Creating mirrored queues via STOMP

Fri Oct 21 08:24:29 BST 2011

On 21/10/11 01:53, Steve Powell wrote:
> Hi Toby,
>
> Unfortunately it is not possible to set ha policy or ttl
> settings on a rabbit STOMP-created queue. [1] [2]
>
> However, it is possible to send to and subscribe from
> a queue created in AMQP using /amq/queue/<name>
> destinations inSTOMP. These queues can have any of the
> rabbit-supported properties.
>
> We currently have an enhancement under discussion that
> puts these headers on SUBSCRIBE or SEND, so that the
> STOMP adapter can create the right sort of queue; but
> we are not sure what to do if the header values disagree
> on two commands referring to the "same" queue.
>
> The STOMP protocol design makes it hard to define queue
> properties, as opposed to message properties, since
> queue-creation is implicit and conditional. It would be
> a surprise if one application sets a queue property and
> another removes it or resets it (or fails if the property
> is different).
>
> A description of your application which requires this
> would help us with future design.

Hi Steve,
It's nothing terribly complex.

There are several applications which generate task requests; they 
generate hundreds of these very rapidly, but only from time to time.

The tasks go through several stages. Each stage has some application 
servers that are subscribed to a queue to process precisely one request, 
then enqueue a new message for the next stage.

RabbitMQ works to hold the queue of pending tasks at each stage. Each 
stage has a separate queue. The backlog of messages surges up to a few 
hundred, then back down to zero as they get processed.

It all works quite nicely, but if I power off one of the two nodes in 
our rabbitmq cluster, then there's a 50% chance we have just lost all 
the messages in some queues. The messages are all marked as persistent, 
so as long as the machine recovers, they'll be safe.. but there's still 
a pause until you fix the machine.

So I was thinking the mirrored queues would work well for us - if a 
machine dies, then it's OK, messages will still carry on being processed 
out of the backlog.

Cheers,
Toby