Clarify behaviour of subscriptions

Matt Mower

unread,

Jan 21, 2012, 3:40:38 PM1/21/12

to stomp-spec

Hi.

I'm looking at using STOMP to provide real-time notifications to
client applications running on multiple machines. That is to say, to
broadcast a message from one point to multiple other points with each
point receiving the same message. In STOMP terms having multiple
clients subscribed to a topic and all receiving every message sent to
the topic by any of them.

I did some initial tests and this seemed to be how the STOMP server I
was using (http://stompserver.rubyforge.org/) worked. However having
come back to the project I am finding that I'm seeing a different
behaviour with only one client receiving messages. It's possible I
have some other error in my client or server code but I thought I
would refer to the spec and see what behaviour was claimed.

I can't actually find anything that describes what I should expect in
this regards.

Have I misunderstood the way STOMP is meant to operate?

I would appreciate any help you could give me.

Kind Regards,

Matt

Brian McCallister

unread,

Jan 25, 2012, 12:10:06 PM1/25/12

to stomp...@googlegroups.com

Stomp defines the protocol used for talking with the server, but it
doesn't describe what the server does. The publish/subscribe model you
describe is a common one and most servers support it, but that
behavior is not defined by Stomp itself.

Looking at the stompserver docs, it seems to focus on just queues
(single consumer per message) rather than pubsub/topics. Other
implementations are available which do support pubsub though, see
http://stomp.github.com/implementations.html for a bunch. I will let
the folks implementing servers weigh in on which you should consider
using ;-)

-Brian

Matt Mower

unread,

Jan 25, 2012, 12:17:25 PM1/25/12

to stomp...@googlegroups.com

Hi Brian.

On Wednesday, 25 January 2012 at 17:10, Brian McCallister wrote:

> On Sat, Jan 21, 2012 at 1:40 PM, Matt Mower <matt....@gmail.com (mailto:matt....@gmail.com)> wrote:
> Have I misunderstood the way STOMP is meant to operate?
>
> Stomp defines the protocol used for talking with the server, but it
> doesn't describe what the server does. The publish/subscribe model you
> describe is a common one and most servers support it, but that
> behavior is not defined by Stomp itself.

Ok, that's useful to know.

>
> Looking at the stompserver docs, it seems to focus on just queues
> (single consumer per message) rather than pubsub/topics. Other
> implementations are available which do support pubsub though, see
> http://stomp.github.com/implementations.html for a bunch. I will let
> the folks implementing servers weigh in on which you should consider
> using ;-)

It's a bit of a puzzle. As you say the docs and my recent experience is "queue" yet when I used it 6 months ago I seemed to be getting "pub/sub". And I didn't update the server in the meantime. I'm a bit baffled since I can't imagine how I could have mistaken the one for the other in the past, yet...

I picked the Ruby implementation because I've primarily been a Ruby developer the last 5-6 years and the relatively simplicity of it appealed to me. But I'm by no means sold on it and would appreciate hearing from others about better choices I could make.

m/

--
http://mattmower.com/