[standards-jig] JEP-0024: Publish/Subscribe - Topic based messaging
jabber at figroll.com
Fri May 10 20:21:30 UTC 2002
Sorry, been away, and then a MAJOR screw up with my mail meant I missed
On Sun, Apr 28, 2002 at 10:25:27AM -0700, Iain Shigeoka wrote:
> One major efficiency boost can be had by filtering messages at the publisher
> rather than at the subscriber endpoint of the queue. This means pushing the
I think my idea of a what a publisher's capabilities are is much simpler. I
expect that a publisher is pretty dumb. When it has some data, it publishes
on some topic (determined by the published). It's only connected to one
broker so that broker then becomes responsible for passing it on to other
brokers that might need that piece of information. Of course, the notion of
having the publish send it to more than one broker is also plausible. I'm not
sure which is best.
> Time outs on messages is a good idea. My scenario though is a bit different.
> Imagine we have a queue with 3 subscribers online. A message is published.
> The server/broker pushes the message out to all three. Now one subscriber goes
> offline but remains subscribed. A message is published. 2 subscribers are
> online, the messages is pushed out to the two subscribers, and stored for the
> other subscriber. One of the 2 subscribers disconnects but remains subscribed.
> Another message is published. It is directly delivered to the remaining
> online subscriber, but is stored for delivery to the 2 offline subscribers.
> The first message in the queue is waiting for one subscriber to take it. the
> second message in the queue is waiting for 2 subscribers to take it.
OK. This is where i'd treat this like a Gordian knot and ignore all the complications!
When any of the subscribers reconnect, they may or may not request the last message
on given topic. If they were offline when anything else was sent, they missed it
and they wont be seeing it again, unless it was the last message. So the broker
only retains one message at any time.
I think the difference is that I'm not guaranteeing that the messing is delivered
to all relavent subscribers. In many applications this is sufficient - afterall
if the subscriber isn't online to deal with the message when it arrives then it
probably can't do anything about it later when it reconnects.
There should be scope for having assured delivery though as you describe. I think
both should be provided for. It should then be down to the application programmer
to decide which QoS they require.
> subscriber is asking for it. The server won't know when it can safely get rid
> of a message and will have to save all messages indefinitely.
Maybe this is an even higher QoS that the application programmer can request at
his secondary storage space's peril...
More information about the Standards