[rabbitmq-discuss] RabbitMQ stomp-adapter behaviour

[Nicolas Echaniz]

Hello everyone,

There has recently been a discussion[1] in the Orbited[2] mailing list -to 
which I'm cc'ing this message-  about using RabbitMQ + stomp-adapter as STOMP 
Broker for a "comet" web-chat sample application.

The problems began when I replaced Orbited's own rather simple STOMP Broker 
(called morbid) with RabbitMQ + stomp-adapter. After configuration, the sample 
code worked fine, but the messages sent were not received by every client 
subscribed to the destination.

I found out that this was the RabbitMQ interpretation of how the broker should 
behave by reading some docs in your site[3] and a thread in your mailing 
list[4].

So I adapted my sample code to make it work with RabbitMQ in "broadcast 
behaviour".
As of his writing, you can find a running sample at:
http://www.proyectomutuo.org/live/public

Having solved this matter I started looking into the matter of subscribing my 
Django app to the STOMP broker. Before starting, I looked into the stomper 
Python module code to see if I'd be able to send the extra-headers that 
RabbitMQ needs to behave as I need it to, but it I found out that I wouldn't.

So a new thread[5] started in the Orbited list.

This lead me to re-read the STOMP Protocol spec[6] and judjing from the 
different clients code I've looked at it looks like everyone else's 
understanding of this paragraph:

"The SUBSCRIBE command is used to register to listen to a given destination. 
Like the SEND command, the SUBSCRIBE command requires a destination header 
indicating which destination to subscribe to. Any messages received on the 
subscription will henceforth be delivered as MESSAGE frames from the server to 
the client."

... is that if a client has subscribed to a destination, then it should 
receive every message that is sent to that destination - what you call 
"broadcast" behaviour in your docs.


So now I'm writing here because it seems to me rather odd that every STOMP 
client code should be modified to be able to send extra-headers to RabbitMQ  
when they seem to be correctly implementing their STOMP Clients according to 
the spec.
Although I must agree that the spec text is rather ambiguous on this matter, I 
believe that interoperability with existing clients is important here and it 
looks to me like non-STOMP extra-headers should not be required from the 
client in order to achieve what seems to be a rather common use case of a 
producer broadcasting to every subscribed consumer and not just to any of them 
(round-robinish behaviour).


I've been reading a lot these days and chose RabbitMQ over the other 
alternatives because it looks like the best alternative in terms of 
performance, reliability, and scallability but I'm not all too sure that 
"fixing" the client libraries myself is the way to go, considering that the 
stomp-adapter is still experimental code.


An Orbited user (who has come across the same issue) has offered to work on 
the erlang stomp-adapter code if needed.


I look forward to reading from you.

If I happen to sound rude or unpolite, please pardon my english... it's not my 
mother tongue.


Cheers,

NicoEchániz

[1] http://groups.google.com/group/orbited-
users/browse_thread/thread/e6a2a4d1bf13eda1
[2] http://www.orbited.org
[3] http://dev.rabbitmq.com/wiki/StompGateway
[4] http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2008-
September/001784.html 

[5] http://groups.google.com/group/orbited-
users/browse_thread/thread/896d37d61dceb073

[6] http://stomp.codehaus.org/Protocol