On Wed, Mar 6, 2013 at 9:01 AM, Michael Goulish <mgoul...@redhat.com> wrote:
>
>
> ----- Original Message -----
> >
> >
> > ----- Original Message -----
> > > From: "Ted Ross" <tr...@redhat.com>
> > > To: proton@qpid.apache.org
> > > Sent: Wednesday, March 6, 2013 10:35:47 AM
> > > Subject: Re: put vs. send
> > >
> > >
> > > On 03/06/2013 10:09 AM, Rafael Schloming wrote:
> > > > On Wed, Mar 6, 2013 at 6:52 AM, Ted Ross <tr...@redhat.com>
> > > > wrote:
> > > >
> > > >> On 03/06/2013 08:30 AM, Rafael Schloming wrote:
> > > >>
> > > >>> On Wed, Mar 6, 2013 at 5:15 AM, Ted Ross <tr...@redhat.com>
> > > >>> wrote:
> > > >>>
> > > >>> This is exactly right. The API behaves in a surprising way
> > > >>> and
> > > >>> causes
> > > >>>> reasonable programmers to write programs that don't work. For
> > > >>>> the sake of
> > > >>>> adoption, we should fix this, not merely document it.
> > > >>>>
> > > >>> This seems like a bit of a leap to me. Have we actually seen
> > > >>> anyone
> > > >>> misusing or abusing the API due to this? Mick didn't come
> > > >>> across
> > > >>> it till I
> > > >>> pointed it out and even then he had to construct an experiment
> > > >>> where he's
> > > >>> basically observing the over-the-wire behaviour in order to
> > > >>> detect it.
> > > >>>
> > > >>> --Rafael
> > > >>>
> > > >>>
> > > >> The following code doesn't work:
> > > >>
> > > >> while (True) {
> > > >> wait_for_and_get_next_event(&**event);
> > > >> pn_messenger_put(event);
> > > >> }
> > > >>
> > > >> If I add a send after every put, I'm going to limit my maximum
> > > >> message
> > > >> rate. If I amortize my sends over every N puts, I may have
> > > >> arbitrarily/infinitely high latency on messages if the source of
> > > >> events
> > > >> goes quiet.
> > > >>
> > > >> I guess I'm questioning the mission of the Messenger API. Which
> > > >> is the
> > > >> more important design goal: general-purpose ease of use, or
> > > >> strict
> > > >> single-threaded asynchrony?
> > > >
> > > > I wouldn't say it's a goal to avoid background threads, more of a
> > > > really
> > > > nice thing to avoid if we can, and quite possibly a necessary
> > > > mode
> > > > of
> > > > operation in certain environments.
> > > >
> > > > I don't think your example code will work though even if there is
> > > > a
> > > > background thread. What do you want to happen when things start
> > > > backing up?
> > > > Do you want messages to be dropped? Do you want put to start
> > > > blocking? Do
> > > > you just want memory to grow indefinitely?
> > >
> > > Good question. I would want to either block so I can stop
> > > consuming
> > > events or get an indication that I would-block so I can take other
> > > actions. I understand that this is what "send" is for, but it's
> > > not
> > > clear when, or how often I should call it.
> > >
> >
> > This begs a question that was asked before (by Mick, I believe) -
> > what happens if a put() message can _never_ be sent? The
> > destination has gone away and will never come back. AFAIK, every
> > further call to send() will block due to that stuck message. How
> > should that be dealt with? Use a TTL?
> >
>
>
>
>
> Well, I just tried it.
>
>
> Setup
> -------------------------------
>
> Set up a receiver to receive, get, and print out messages in a loop.
> ( receive blocking, i.e. timeout == default )
>
> Then start a sender (default timeout) that will:
>
> 1. put-and-send message 1.
> 2. put message 2.
> 3. countdown 12 seconds before it decides to send message 2.
> 4. send message 2.
>
> While the sender is getting ready to call send() on msg2, I kill the
> receiver.
>
>
>
> Result
> -----------------------
>
> I see the receiver print out message 1. good.
> When the sender has put() msg2 but not yet sent(), I kill receiver.
> Sender calls send() on message2.
> send() returns immediately, return code is 0. (success)
>
>
>
> Analysis
> --------------------------
>
> Bummer. Dropped message.
>
If you want reliability you need to check the status of the tracker you get
when you call put(). You would also need to set a nonzero outgoing window
so that messenger actually retains that status.
--Rafael
