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









> 
> > >
> > > --Rafael
> > >
> > 
> > 
> 
> --
> -K
> 

Reply via email to