----- Original Message ----- > On Tue, Mar 5, 2013 at 11:10 AM, Ted Ross <[email protected]> wrote: > > > > > On 03/05/2013 02:01 PM, Rafael Schloming wrote: > > > >> On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish > >> <[email protected] > >> >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 >
