Ask for clarification of ACK

[Jeff Xiong]

Hi there.

I'm thinking about the behavior of ACK. According to the protocol spec,

"When a client has issued a SUBSCRIBE frame with the ack header set to
client any messages received from that destination will not be
considered to have been consumed (by the server) until the message has
been acknowledged via an ACK."

Then what should the broker do if it sends out the message but can't
get ACK from client? Should it resend? What if the client goes down?
Should the broker store the message in some persistent manner and wait
for another subscriber? Can someone help me to answer the question?

--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://stomperl.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[andrewk]

Jeff Xiong wrote:

Then what should the broker do if it sends out the message but can't
get ACK from client? Should it resend? What if the client goes down?
Should the broker store the message in some persistent manner and wait
for another subscriber? Can someone help me to answer the question?
--
Jeff Xiong

I can tell you what the activemq broker seems to do - if you don't ack a message in client ack mode, it waits and never sends another message to that connection. Period.  I have not seen a timeout on the broker side, it seems happy to wait.  

If the client connection goes down, then activemq will assume the message was not processed by that connection, returns the message to the queue, and a different client connection will be able to get the message.  In fact, the only way I have found to un-ack a message (give it back, so to speak) is to sever the connection and reconnect.  

As for persistence, activemq is already persisting all messages based on your config, and will only send the message to a different subscriber if it loses connection to the orignal subscriber who has not ack-ed.

I'm basing this on my observation, not a deep look at the code so if an AMQ dev wants to correct me, I'm all ears.

Hope that helps,
-Andrew Kuklewicz

[Jeff Xiong]

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.

On Dec 14, 2007 9:59 PM, andrewk <andrew@...> wrote:

>
>
> Jeff Xiong wrote:
> >
> > Then what should the broker do if it sends out the message but can't
> > get ACK from client? Should it resend? What if the client goes down?
> > Should the broker store the message in some persistent manner and wait
> > for another subscriber? Can someone help me to answer the question?
> > --
> > Jeff Xiong
> >
>
> I can tell you what the activemq broker seems to do - if you don't ack a
> message in client ack mode, it waits and never sends another message to that
> connection. Period.  I have not seen a timeout on the broker side, it seems
> happy to wait.
>
> If the client connection goes down, then activemq will assume the message
> was not processed by that connection, returns the message to the queue, and
> a different client connection will be able to get the message.  In fact, the
> only way I have found to un-ack a message (give it back, so to speak) is to
> sever the connection and reconnect.
>
> As for persistence, activemq is already persisting all messages based on
> your config, and will only send the message to a different subscriber if it
> loses connection to the orignal subscriber who has not ack-ed.
>
> I'm basing this on my observation, not a deep look at the code so if an AMQ
> dev wants to correct me, I'm all ears.
>
> Hope that helps,
> -Andrew Kuklewicz
>
> --
> View this message in context: http://www.nabble.com/Ask-for-clarification-of-ACK-tp14329341p14336210.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
>
>

--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://stomperl.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[andrewk]

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

[Jeff Xiong]

Yeah, that really helps. Your explanation about these two patterns
makes my mind clear. Thanks a lot.

On Dec 15, 2007 12:12 AM, andrewk <andrew@...> wrote:

>
>
>
> 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
>
>

--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://stomperl.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email