qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Goulish <mgoul...@redhat.com>
Subject Re: message disposition question
Date Tue, 23 Apr 2013 14:09:06 GMT
Oh!  Oh!  Let me try!   (see inline)

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

First, just to be clear, it's not in the background in the sense of
a separate thread, it's just ... 'unexpectedly'.

But the main thing is .. .that is not a *received* window.    
If you set a window size of N, that window exists only
relative to the position of the first message for which you 
create a tracker.

Creating a tracker is done not with recv() but with get(),
and the window only exists in the get-space.  Not in the 
recv space.

So the only way to make a message fall off the window is to:

  0. define incoming window size N

  1. call get()

  2. make a tracker  ( will track starting with most recent message got() )

  3. call get() N more times, but don't both to dispose the messages one
     way or the other.

  4. You just had 1 message fall off the edge of your window, and
     get accepted by default.
  5. If you keep calling get() now, you will have 1 new message fall 
     over the edge for each call.

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

Don't know.  Brain tired.
I think you can't  -- but at least they won't fall
out the window.

> Cheers,
> Alan.

View raw message