On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish <mgoul...@redhat.com>wrote:

>
> quoth Rafi:
>
> > The semantics of pn_messenger_put allow it to send if it can do so
> without
> > blocking.
>
>
> 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.


>
> The only transmission difference between put() and send() is that send()
> will actually block until they're all sent (or timeout hits).  put() should
> get rid of all the messages that aren't blocked, and leave all that are.
>
> . . .
>
> Because what I'm seeing is -- with my receiver hanging in recv(),
> I put 5 messages.  Sender sits there for a while.  No messages arrive at
> receiver.  Then sender calls send() -- and all 5 messages arrive at
> the receiver.
>
> This is true whether on the receiver side, I use
>
>    pn_messenger_recv ( messenger, 100 );
>    pn_messenger_recv ( messenger, 5 );
>    pn_messenger_recv ( messenger, 1 );
>    or
>    pn_messenger_recv ( messenger, -1 );
>
>
> That's why it seemed two-stage to me.  put() seems to gets them staged,
> send() seems to shove them out the door.
>
> No?
> Or is this a bug?
>

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.

--Rafael

Reply via email to