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
> --
> View this message in context: http://www.nabble.com/Ask-for-clarification-of-ACK-tp14329341p14338751.html
>
> Sent from the stomp - dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>