On Wed, Mar 6, 2013 at 8:38 AM, Ken Giusti <kgiu...@redhat.com> wrote:

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

Send() won't block in this case, if the message is rejected or the
destination doesn't exist you can find out by checking the status via the
tracker you get when you call put.

--Rafael

Reply via email to