[rabbitmq-discuss] Broadcasting and STOMP (was Re: python stomp examples)

Wed Sep 10 12:34:16 BST 2008

Hi Joe,

Novak Joe wrote:
> First I wanted to thank you for this post

Glad I could help. I'll use it as feedstock for growing the README and
the wiki page (https://dev.rabbitmq.com/wiki/StompGateway), too.

> Is this round-robin functionality predictable in terms of the order in
> which a set of consumers subscribed to a single queue will be
> notified?

It's not perfect. It will *usually* be a fairish round-robin, cycling
through consumers in a regular cycle. If anything happens, though, such
as the addition or removal of a consumer, or the rejection of an
individual message, or TCP flow-control kicking in, the order of
consumers can be shuffled. Usually the shuffling will be minor, but it
can in general be arbitrary.

>> The "id" header should be some string unique to the current connection
>> (!) which names the subscription. I've used a fresh GUID here, but
>> anything connection-unique is acceptable.
> Would there be any argument against using some version of a GUID-style
> browser session cookie here?  This would provide me with a nice
> mapping to my web application as well, to help keep things organized.

No argument against that. So long as the "id" string there is unique to
the individual STOMP connection (socket), you're good to go.

> Thanks for this link, although maybe I should have looked harder for
> the spec myself.  Instead I fruitlessly searched about the rabbitmq
> site for 'fanout' and 'topic'.

We're working on improving the website and the wiki.

> Based on the AMQP spec it looks like a topic exchange is best suited
> to my needs.  This provides the same basic functionality as the
> fanout, but also provides added granularity in terms of determining
> who gets what in a hierarchical fashion ( I guess it doesn't
> necessarily have to be hierarchical though ).

Yes. Note that fanout is a bit more efficient in the current implementation.

> Hmm.  From the AMQP spec it looks like I can create a 'durable'
> exchange, which means that there shouldn't be any obstacle to creating
> a hybrid producer client, right?  I am working primarily with python,
> so I'm thinking I can use stomper+py-amqplib or python-qpid
> (http://barryp.org/software/py-amqplib/) then just use amqp module to
> add the exchange and do all my message passing with STOMP.

Absolutely. That sounds right to me.

Regards,
  Tony
-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ | Email: tonyg at lshift.net