[rabbitmq-discuss] RabbitMQ stomp-adapter behaviour
nico at rakar.com
Mon Jun 8 03:40:23 BST 2009
There has recently been a discussion in the Orbited 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 and a thread in your mailing
So I adapted my sample code to make it work with RabbitMQ in "broadcast
As of his writing, you can find a running sample at:
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 started in the Orbited list.
This lead me to re-read the STOMP Protocol spec 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
... 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
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
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
More information about the rabbitmq-discuss