qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: message disposition question
Date Tue, 23 Apr 2013 13:56:12 GMT
On 04/18/2013 06:21 AM, Rafael Schloming wrote:
> I spoke a bit too soon in my first reply. The tracking windows are
> *supposed* to be measured from the point where the tracker is first
> assigned, so from when you call put or get. This means that it shouldn't
> matter how many times you call recv or how much credit recv gives out, the
> only thing that matters is whether you've called get() more than WINDOW
> times. That should be fine as calling get() is very much in your control.
> Now the reason I was confused yesterday is that from looking at the code it
> appears that due to a recent commit, incoming trackers are actually
> assigned earlier than they should be. This has not been the case for any
> released code, however, only for a short time quite recently on trunk.
> --Rafael
> On Wed, Apr 17, 2013 at 2:26 PM, Rafael Schloming <rhs@alum.mit.edu> wrote:
>> That's a good question and now that you mention it nothing prevents it.
>> That was an intentional choice when the feature was added, and it wasn't a
>> problem at the time because we didn't have recv(-1). This meant that you
>> were always asking for an explicit amount and if you asked for more than
>> your window, you were (hopefully knowingly) asking for trouble. With
>> recv(-1), however, you are no longer explicitly controlling the credit
>> window so this could be a problem. One possibility might be to define
>> incoming/outgoing window sizes of -1 to allow for unlimited sizes.
>> --Rafael
>> On Wed, Apr 17, 2013 at 1:32 PM, Michael Goulish <mgoulish@redhat.com>wrote:
>>> ( a question inspired by a question from a reviewer of
>>> one of my docs... )
>>> If you set an incoming message window of a certain size,
>>> and if Messenger can receive messages even when you, i.e.
>>> call send() - - -  what's to stop some messages from
>>> falling off the edge of that window, and thus getting
>>> accepted-by-default, before your app code ever gets a
>>> chance to make a real decision about the message's disposition ?

I'm still not clear on how this answer the original question: If messages can be 
received "in the background" when I call send() or other functions, and that can 
cause messages to fall out of the received window, then how do I ensure that I 
get a chance to see and ack/reject every message? I have no control over the 
background message delivery.

A related question: how can I flow control if I'm getting too many messages? The 
naive answer is "stop calling recv()" but if messages can also be received when 
I call send() then I have no way to limit the messages that pile up, or worse: 
that are dropped off my receive window and into oblivion.


View raw message