[rabbitmq-discuss] RabbitMQ stomp-adapter behaviour

Gavin M. Roy gmr at myyearbook.com
Tue Jun 9 16:06:14 BST 2009

On Tue, Jun 9, 2009 at 1:09 AM, Matthias Radestock <matthias at lshift.net>wrote:

Please take this in context in that I am migrating a large scale ActiveMQ
install using STOMP to RabbitMQ and am looking to mirror default behaviors.
 That being said, I've changing the default behaviors in the stomp connector
when I download it so that I get the behaviors I need by default.

The default behaviour of the current implementation of the RabbitMQ
> STOMP adapter
> 1) routes messages to one consumer (round-robin) - this can be changed
> to 'all' by specifying appropriate 'exchange' and 'routing_key' headers

+1 This is good.

2) does not queue messages when there are no subscribers - this can be
> changed by specifying an 'auto-delete = false' header (though that does
> require at least one SUBSCRIBE to start with)

I change this auto-delete = false in the code before compilation to mirror
ActiveMQ behavior.

 3) sends only one copy of a message to a client in the event the client

> has more than one subscription for the same destination - this can be
> changed by specifying  appropriate 'exchange' and 'routing_key' headers

+1 This makes sense.

> Should the default behaviour be different? And why?

The only other oddity is the durable consumer.  Coming from an ActiveMQ
world, this is more of a server side setting than a header packet setting.

For what it's worth is the biggest issue I had to overcome (other than the
client issues) was the concept that one has to subscribe to a queue in order
to set the default behavior for it.  Our workflow has apps enqueueing all
over the place and a limited set of consumers that can be restarted or down
for small periods of time.  The natural flow for us is to start enqueueing
then add consumers that subscribe, not the other way around.  If the queue
behavior can be set when messages are sent, it would make things easier to
grok.  Even more ideal would be to set defaults by exchange, but that
probably is more work than is reasonably obtained, compared to just changing


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090609/7d53ce76/attachment.htm 

More information about the rabbitmq-discuss mailing list