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
2) never bother transmitting anything until you force it to by calling
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.