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);
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
