[rabbitmq-discuss] RabbitMQ stomp-adapter behaviour

Thu Jun 11 07:06:49 BST 2009

On Wednesday 10 June 2009 09:29:10 you wrote:
> On Mon, Jun 8, 2009 at 03:40, Nicolas Echaniz<nico at rakar.com> wrote:
> > 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:
> >
> > ... 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.
>
> As far as I understand, rabbit-stomp gateway implements
> a subset of AMQP features - but over a STOMP protocol.
>
> For example a STOMP 'destination' is treated as an AMQP 'queue',
> but this abstractions represent slightly different thing.
>
>
> As Matthias pointed out, STOMP spec doesn't give much information
> of what the defaults should be. The problem is that even if changing
> the defaults is easy, we must take care of all the other use cases.

I agree that it seems impossible to take care of every use case with one 
dafault behaviour. The problem I see with the RabbitMQ approach here is the 
need for extra headers in order to get the desired behaviour, because many 
STOMP client libraries do not contemplate the use of extra headers at all, 
which is really fine from the point of view of the (rather sucint) STOMP spec.

What I believe would be a good approach at the moment is to let the user 
select the desired "defaults" for the stomp-adapter in their rabbitmq.conf 
file somehow.

There could be settings for all the key questions that Matthias enumerated:
1) Should messages be routed to all subscribers or just one (round-robin)?
2) Should messages be queued when there are no subscribers?
3) When a client has multiple subscriptions to the same destination,
    should they receive one copy of a message or several?

For example:

1) MESSAGE_ROUTING = queue | topic   (or round-robin|broadcast)
2) ALWAYS_QUEUE = true | false
3) UNIQUE_SUBSCRIPTION = true | false

I really wouldn't mind what the "factory defaults" are as long as I can tweak 
them for my deployment through a conf file.

One other thing... there has been much discussion in the Orbited IRC channel 
about the flaws in the STOMP spec and Michael Carter (Orbited dev) has 
proposed the creation of a better protocol that should be as much backwards 
compatible with STOMP as possible but specifies things more precisely.

I believe this could be the only real solution to the STOMP interoperability 
problems... What do you guys think?

--
NicoEchániz