On Tue, Mar 5, 2013 at 12:39 PM, Michael Goulish <mgoul...@redhat.com>wrote:
> > > ----- 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? > When a messenger is blocked it will do whatever outstanding work it can. This won't necessarily cause all messages to be sent, but it may cause some. > Is that symmetric? Does a call to send() also cause > messages to be received ? > Yes it is symmetric, messages can arrive while you're blocking for send(). --Rafael
