[rabbitmq-discuss] Durable queues for STOMP broker
sean at soundcloud.com
Mon Jun 2 12:17:48 BST 2008
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
> 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
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.
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
while msg = conn.receive
More information about the rabbitmq-discuss