[rabbitmq-discuss] Creating mirrored queues via STOMP

[Steve Powell]

Toby,

If the queue structure is fixed then the STOMP adapter 
need not create them, and so it might be sensible to 
create them beforehand, and use STOMP destinations of 
/amq/queue/<name> as I suggested.  

Instead of using STOMP to create them, create some 
shared queues using a richer protocol, say with the 
Java Client, or the Erlang Client, or even Python 
(gasp). The queue headers are then arbitrary and the 
STOMP applications will only have to SEND and 
SUBSCRIBE to the /amq/destinations and not be 
concerned with any operational characteristics of the 
queues.

The (slight) downside is that the queues are managed
separately from the main apps, and you might have some
more operational steps at restart/backup/upgrade
events to consider. I'm morally certain you already 
have a place to put those extra steps.
 
Steve Powell  (a happy bunny)
----------some definitions from the SPD----------
Rigatoni n. A prime-ministerial grin.
Nigella n. The next bottle-size up from a Nebuchadnezzar.
Homily adv. Rather like a frenchman.

On 21 Oct 2011, at 08:24, Toby Corkindale wrote:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111021/4b5ea5f5/attachment.htm>