[rabbitmq-discuss] Durable queues for STOMP broker
tonyg at lshift.net
Sun Jun 1 11:05:58 BST 2008
Sean Treadway wrote:
> Attached are 2 patches from my findings on how to expose some of the
> method parameters as STOMP headers. They include the following changes:
Thanks very much for these. They look good. I'll apply them.
> * 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 also found a bug in message persistence over server restarts in
Well spotted. As you mention, this doesn't affect the core broker, or
any AMQP-speaking clients; it's limited to other transports. Your patch
will no doubt make life easier for future other-transport writers :-)
> 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?
> Points I am unsure about are - the role
> of the 'passive' parameter to queue.declare,
"passive" essentially checks that the queue exists without creating it.
If it doesn't exist, an error is signalled. I'll check to make sure the
behaviour of the STOMP adapter in this case is sensible.
> whether or not to expose
> the 'nowait' parameter,
Probably best not. Well, not until we run into a case where it's needed,
anyway - it's a bit of a nasty hack to work around the lack of
pipelining in 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
> interoperability of the
> properties patch for brokers such as HTTP and regression of the
> properties patch against AMQP messages with binary properties.
It seems safe to me, since less information is discarded after your
patch than before.
> 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.
Thanks again for the contribution,
More information about the rabbitmq-discuss