[rabbitmq-discuss] Durable queues for STOMP broker

[Sean Treadway]

Hi Tony,

Thanks for applying the patch!  I see you caught that commented line  
in the ruby receiver example - thanks.

On Jun 1, 2008, at 12: 05, Tony Garnock-Jones wrote:

>> * expose 'passive', 'durable', 'auto-delete', 'exclusive'  
>> parameters of the AMQP 'queue.declare' method as STOMP headers in  
>> SUBSCRIBE
>
> Hmm, naming and interoperability. While we're still in  
> "experimental" status we can use any names we like, of course, but  
> I'd be interested to compare and contrast the names we choose for  
> things like this with the names other STOMP-supporting brokers use  
> for similar features.
>
> Does anyone on the list have any comments around this area?
>
> On a related note, what do you think about trying to more generally  
> expose more of the AMQP functionality over STOMP? We could look at  
> ways of using the AMQP protocol definition to autogenerate the  
> necessary marshalling code, just as we do for other transport and  
> protocol bindings.

I chose the AMQP naming for this patch because I used the AMQP  
documentation to learn/understanding the intended behavior of queue  
declaration.  I took a quick trip over to ActiveMQ's documentation  
pages and saw that they had similar configuration with their own/ 
different naming but I consciously thought "This is not ActiveMQ, this  
is RabbitMQ.  I want to know that to leverage RabbitMQ features".   
STOMP looked like it was MQ agnostic and extensible while keeping the  
core headers well defined (ack=client, message_id, etc...), but my  
application was not MQ agnostic.  Plus I saw some of the ActiveMQ  
headers weren't available or necessary in RabbitMQ.

Keeping the AMQP naming is the best way to piggy back on the AMQP  
documentation.  For those that need simple, transient queues, the  
existing STOMP documentation would be sufficient.

>> Big thanks to you all at LShift for building this beautiful code.
>
> You're welcome! I take it you're using Ruby to interact with the  
> broker - have you tried any of the available Ruby AMQP clients out  
> there? Can you share with us what kind of thing you're doing with  
> RabbitMQ?

We're using RabbitMQ as a job dispatcher for our media transcoder  
machines and for our 1-many notification broadcasts (upload a track,  
your fans are notified).

We chose RabbitMQ because after reading Joe's book on Erlang, OTP  
quickly became the best choice for meeting the requirements of fail- 
tolerance and scalability.  Pure throughput wasn't an issue for us.

I've been keeping an eye on RabbitMQ for about a year, and have to  
admit that the language tone and 'heaviness' around AMQP kept me from  
adopting it in a previous project.  The tone of rabbitmq.com was much  
more accessible, so I had faith that this was an open source project  
with dedicated maintainers so I put it on top of my list of MQ  
candidates when I needed the reliability and could invest in this part  
of our infrastructure.

I remember reading somewhere long ago that ruby AMQP lib was  
incomplete and not very stable.  The ruby source seemed complicated  
and did much more than what we needed.  AMQP solves a lot of problems,  
most of which I am unfamiliar with.

When the STOMP broker was released I thought "great! STOMP looks just  
like HTTP".  I grabbed the ruby lib, understood it, and thought that  
if anything went wrong, I could fix it.  With RSS and XMPP experience,  
it was easy for me to see how the publish-subscribe model we needed  
was implemented in STOMP.

If we need anything more complicated like setting up custom exchanges  
or finer control over routing, we'll probably switch to AMQP.

>> whether or not to try and match ActiveMQ's STOMP header names or  
>> stick with the AMQP naming,
>
> This is a great question. I'd love to hear your thoughts on the  
> subject, not being familiar myself with any other broker-specific  
> options and headers.

I only have experience with RabbitMQ, so I'm fine with exposing AMQP  
rather than try to come to some agreement over the extension names of  
standard STOMP headers.  Since I'm new around here, don't really know  
the relationship between the RabbitMQ and ActiveMQ communities.  If  
we're all in this together and have good communication, it may be  
worth the effort to harmonize on the naming.  "What does consisting  
naming across broker vendors give the consumers of our MQ" may be the  
right question to ask.

>> Also, the STOMP spec gives no insight for queue deletion when a  
>> durable queue is no longer needed.  Any ideas for that one?
>
> Good point. I think we're probably pretty free to implement  
> extensions of our own in this area - how about a "DELETE" command?  
> This touches on my question above of how best to expose more of AMQP.

Here, I would stick with the verbs defined in STOMP and extend the  
verbs with headers.  One possibility is to use UNSUBSCRIBE messages to  
change the queue properties before sending the 'basic.cancel' method.   
Another possibility is to change queue properties on a SUBSCRIBE  
message. Neither seem nice to me.  Third option is to do nothing, and  
delete the queues outside of the STOMP protocol (we're fine with that  
as we have a fixed number of persistent queues).

How are auto-delete=false queues removed with AMQP?

On Jun 1, 2008, at 23: 28, Tony Garnock-Jones wrote:
> By the way, is it just me, or does the Ruby STOMP adapter get very  
> confused when the socket closes underneath it? I see fairly  
> consistent behaviour of 100% CPU usage, with the Ruby program just  
> spinning, if the socket's closed by the server for whatever reason.  
> Odd!

This was in the example's receive loop and not in the library itself,  
the 'nil' message on socket closure was just being ignored.  Here's a  
receive loop that actually terminates :).  It could also be applied to  
cb-receiver.rb:

while msg = conn.receive
   puts msg.body
end

-Sean