Re: Ask for clarification of ACK

Jeff Xiong wrote:

Well...since I'm not an expert of messaging, I guess it's forgivable
to ask naive questions...

Let's imagine that:

Client1 SUBSCRIBEs destA
Client2 SUBSCRIBEs destA
Client3 SENDs message to destA
Broker sends MESSAGE to Client1
(Client2 goes down without DISCONNECT or UNSUBSCRIBE)
Broker sends MESSAGE to Client2 and fails

Should the broker store and resend message in this case? If not, then
from Client2's perspective, the behavior of the broker changes when
there is or is not another subscriber, which is weird to me.

Jeff Xiong

Your example shows one message being delivered to 2 different clients (first to client1 and succeeded, and then to client 2 and failing).  

So this begs the question, are you following the 'Message Queue' or 'Publish Subscribe' pattern for messaging with this destination?

To put it another way, is the destination in this case a queue or a topic?

If it is a queue, then after the message from client3 is delivered to client1, the broker is done, and will never attempt to send it to client2.  Queues need to deliver a message once, to one subscriber.

If it is a topic, then the broker will publish to both subscribers client1 and 2, and if one fails, so be it, it doesn't need to try and redeliver to a different subscriber because by definition it publishes to all subscribers anyway.

Same with if there are no good subscribers - the behavior depends on the destination type.  If it is a queue, and there are no good subscribers left to send to, then the message sits in the queue and waits (persisted in some way). If it is a topic, it depends: if there are any durable subscriptions (i.e. this is a notion not all brokers have, but some can have clients who have created durable subscriptions that are remembered by the broker whether or not the client is currently connected), then the broker needs to hang on to x number of old messages for these durable subscribers to receive when they next connect.  If there are no durable subscriptions to a topic, and no other normal subscribers, then it has no responsibility to keep messages.  

Brokers can and do vary alot in the details about how to handle message queues and/or  publish & subscribe.  Nothing in stomp that I recall specifies how the broker should handle these issues - the protocol handles the communication, but not the behavior or types of destinations, that is up to the broker implementation.  The two general types, queue and topic, are what you get in JMS for exampl, and many other brokers, but other brokers/protocols like Amazon's SQS only have message queues.

I feel like I am talking about messaging in general - got any stomp related questions?

-Andrew