----- Original Message -----
> On Tue, Mar 5, 2013 at 11:10 AM, Ted Ross <tr...@redhat.com> wrote:
> 
> >
> > On 03/05/2013 02:01 PM, Rafael Schloming wrote:
> >
> >> On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish
> >> <mgoul...@redhat.com
> >> >wrote:
> >>
> >>
> >>> So, am I understanding correctly? -- I should be able to get
> >>> messages
> >>> from my sender to my receiver just by calling put() -- if the
> >>> receiver
> >>> is ready to receive?
> >>>
> >>>  Not necessarily, the receiver being ready just means you are
> >>>  unblocked
> >> on
> >> AMQP level flow control. You could also potentially block on the
> >> socket
> >> write (i.e. TCP level flow control). You need to be unblocked on
> >> both for
> >> put to succeed.
> >>
> >
> > Certainly there is no TCP flow control happening in Mick's
> > scenario.
> >
> >
> >  What I said was put is *allowed* to send optimistically, not that
> >  it is
> >> required to. It actually did send optimistically in a previous
> >> version of
> >> the code, however I commented that line out.
> >>
> >> I would say the documented semantics of put and send should allow
> >> the
> >> implementation the flexibility to do any of the following:
> >>
> >>    1) optimistically transmit whatever it can everytime so long as
> >>    it
> >> doesn't block
> >>    2) never bother transmitting anything until you force it to by
> >>    calling
> >> send
> >>    3) anything in between the first two, e.g. magically transmit
> >>    once
> >> you've
> >> put enough messages to reach the optimal batch size
> >>
> >> The reason for the behaviour you are observing is that we
> >> currently do
> >> option 2 in the C impl, however we've done option 1 in the past
> >> (and I
> >> think we do option 1 still in the Java impl), and we will probably
> >> do
> >> option 3 in the future.
> >>
> >
> > If this is the case, then Mick's original view is correct.  The
> > application must assume that messages will not ever be sent unless
> > "send"
> > is called.  There is no flowing, pipelined, non-blocking producer.
> >
> 
> It's not correct as documentation of the API semantics. It's also not
> correct to say that messages will never be sent unless "send" is
> called,
> e.g. the following code will work fine:
> 
> Client:
>   m.put(request);
>   m.recv(); // wait for reply
>   m.get(reply);



That recv() just caused an enqueued message to be sent?

I just tried it in a C program and it worked, more or less.
At least the receiver got his 5 messages without send() 
ever having been called.

Does a call to recv() also cause all unblocked messages
to be sent?

Is that symmetric?  Does a call to send() also cause 
messages to be received ?




> 
> Server:
>   while True:
>     m.recv(); // wait for request
>     m.get(request)
>     m.put(reply);
> 
> As for there being "no flowing, pipelined, non-blocking producer,"
> that
> seems like an orthogonal issue, and depending on what you mean I
> wouldn't
> say that's necessarily true either. You can certainly set the
> messenger's
> timeout to zero and then call put followed by send to get the exact
> same
> semantics you would get if put were to optimistically send every
> time.
> 
> --Rafael
> 

Reply via email to