[rabbitmq-discuss] Durable queues for STOMP broker

[Tony Garnock-Jones]

Hi Sean,

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 
> rabbitmq-1.3.0.

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 
headers.

> 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.

> 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.

Thanks again for the contribution,
   Tony