Use of mode:browse and session.acknowledge() in topic exchanges

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Use of mode:browse and session.acknowledge() in topic exchanges

Renier Morales
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? 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?

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?

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?

Thanks,

         -Renier


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

Reply | Threaded
Open this post in threaded view
|

Re: Use of mode:browse and session.acknowledge() in topic exchanges

Gordon Sim
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Use of mode:browse and session.acknowledge() in topic exchanges

Renier Morales
On 11/11/13 6:07 AM, Gordon Sim wrote:

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

Thanks for your very helpful response. Would the bug cited also force
the client to ack messages when using an unreliable topic subscription?

      -Renier

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



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

Reply | Threaded
Open this post in threaded view
|

Re: Use of mode:browse and session.acknowledge() in topic exchanges

Gordon Sim
On 11/11/2013 03:54 PM, Renier Morales wrote:
> Would the bug cited also force the client to ack messages when using
> an unreliable topic subscription?

No, it will only affect browsing a queue.

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

Reply | Threaded
Open this post in threaded view
|

Re: Use of mode:browse and session.acknowledge() in topic exchanges

Renier Morales
On 11/11/13 12:06 PM, Gordon Sim wrote:
> On 11/11/2013 03:54 PM, Renier Morales wrote:
>> Would the bug cited also force the client to ack messages when using
>> an unreliable topic subscription?
> No, it will only affect browsing a queue.
>

Ok. We've been seeing that with python-qpid (0.22), we have to ack the
messages back when subscribing to unreliable topic exchanges. Otherwise
we see memory leakage in the python process.


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

Reply | Threaded
Open this post in threaded view
|

Re: Use of mode:browse and session.acknowledge() in topic exchanges

Gordon Sim
On 11/11/2013 06:56 PM, Renier Morales wrote:
> Ok. We've been seeing that with python-qpid (0.22), we have to ack the
> messages back when subscribing to unreliable topic exchanges. Otherwise
> we see memory leakage in the python process.

That sounds like a possible issue with the python client, could you log
a JIRA? (https://issues.apache.org/jira/browse/QPID)

 From what I can see the python client adds every message received to
the unacked list, even if the transfer mode implies that no accept is
expected.


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

Reply | Threaded
Open this post in threaded view
|

Re: Use of mode:browse and session.acknowledge() in topic exchanges

Renier Morales
On 11/12/13 8:37 AM, Gordon Sim wrote:

> On 11/11/2013 06:56 PM, Renier Morales wrote:
>> Ok. We've been seeing that with python-qpid (0.22), we have to ack the
>> messages back when subscribing to unreliable topic exchanges. Otherwise
>> we see memory leakage in the python process.
> That sounds like a possible issue with the python client, could you log
> a JIRA? (https://issues.apache.org/jira/browse/QPID)
>
>   From what I can see the python client adds every message received to
> the unacked list, even if the transfer mode implies that no accept is
> expected.
>
Ok, thanks for checking. I opened QPID-5337[1].

     -Renier

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


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