On 11/11/2013 01:54 AM, Renier Morales wrote:
Hello,

Trying to understand how mode:browse and session.acknowledge() work in
relation to one another.

First, when subscribing as a receiver of a topic exchange, does having
mode:browse in the address options have any effect at all?

No.

Since, as I
understand (or misunderstand), messages are routed to all subscribed
based on the binding key. If this is the case, then mode:browse does not
apply in this case, since you can't keep others from getting the message
in this scenario anyway. True or False?

True.

Assuming the above is true, whether using mode:browse when subscribing
to a queue or not using it when subscribing to a topic exchange, is it
necessary to acknowledge a message in these two instances? For instance,
why would it make sense for the broker to get acknowledged on a message
by a queue subscriber in browser mode?

For a browser you are right, the acknowledgement doesn't signal anything meaningful.

At present the AMQP 0-10 implementation doesn't alter the accept-mode when brose is specified, which means that the broker will continue to track the messages it delivers to a browser unless they are explicitly confirmed through an accept. This however is really a bug in the client[1] and I'll submit a fix for that shortly.

In practice, unless you are browsing a very large number of messages with the same receiver, they lack of an acknowledge would not cause an issue here.

Also, why would a topic subscriber acknowledge the server on messages?
Is this ack status used by the broker to resend the message if the
client breaks its connection for a bit?

A topic subscription can be unreliable (which is the default) or reliable. For an unreliable subscription there is no need to call acknowledge. For a reliable subscription you would call it to indicate successful processing of the message so that if you lose the connection and reconnect, you get only the messages since the last one you acknowledged.


[1] https://issues.apache.org/jira/browse/QPID-5328

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to