Issues using RabbitMQ

[Andrew Bonney]

Hi,

I was just wondering if anyone had successfully managed to implement RadioVIS using a RabbitMQ server? I've been having a quick look at this and seem to be hitting an issue with character encoding requirements. When setting the destination header in a request, RabbitMQ's Stomp plugin appears to reject any '/' characters after '/topic/' (passing back an error), however if a request is made such as '/topic/id%2Frdns.offthechartradio.co.uk%2F etc' this works and in turn shows up correctly in RabbitMQ's management interface ('%2Ftopic%2Fid etc' does not, so its requirements for escaping appear to be very selective). This is alluded to in http://www.rabbitmq.com/stomp.html as I've included below:

"If /, % or non-ascii bytes are in the queuename, exchange_name or routing_key, they are each replaced with the sequence %dd, where dd is the hexadecimal code for the byte."

In that case it's talking about initial setup, but the same seems to apply for requests from clients.

Having tried a couple of RadioVIS viewers and checked the spec, nothing seems to handle this case, so I'd assume no devices do either. I'm planning to look at ActiveMQ instead now (or make a fork of RabbitMQ's plugin), but thought it might be worth flagging this given that RabbitMQ is listed as an example server on radiodns.org

If anyone knows erlang (I don't) and wants to confirm why this is happening, the error is reported by line 440 of https://github.com/rabbitmq/rabbitmq-stomp/blob/master/src/rabbit_stomp_processor.erl, with a parsing/escaping procedure in https://github.com/rabbitmq/rabbitmq-stomp/blob/master/src/rabbit_stomp_util.erl which throws the error. Rather unhelpfully, the first thing it appears to do upon receiving a 'valid' destination including %2Fs is unescape them (and vice versa for sending data back, if I'm interpreting the code right).

Cheers,

Andy

[Ben Poor]

Hi Andrew,

Thanks for your observations - very comprehensive. The short answer to your question is probably 'no' - I've never heard of anyone successfully managing to get RabbitMQ to play nicely with RadioVIS and I certainly haven't had any luck with it either. That said, RabbitMQ is great for an AMQP server.

The Stomp specification is fairly open to the issue of handling path separators in a destination string. The current Stomp 1.0 specification states:

Destination names are simply strings which are mapped to some form of destination on the server - how the server translates these is left to the server implementation

The problem here is that most servers use Stomp connectors which align to the destination name structure of their underlying technology. 

The '/' character was chosen as the path separator for several reasons, one of them that this is the choice of ActiveMQ, being the reference Stomp platform.

Certainly putting a patch on the RabbitMQ Stomp connector would be useful, but can't say I'm too hot on Erlang. Is anyone else on the list able to see what can be done?

Thanks,

Ben

[James Cridland]

Should we remove it from the website?

[Andrew Bonney]

For reference I ended up using Apache Apollo which I see others have tried before (didn't fancy diving into the Erlang!). It seems to work well and avoids a lot of the complication of ActiveMQ, particularly given that it only supports Stomp for now. The setup still wasn't totally straightforward, but it does now seem to work with both the Casterplay and BBC example applications, so I'm happy enough.