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]