<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="Ih2E3d"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>At present, no, there's no explicit flow control mechanism.<br>
</div>
<br>
One option might be to extend the STOMP adapter with an equivalent of AMQP's "basic.get" method, which retrieves a single message at a time from a queue, without using a subscription.<br>
<br>
However, it's worth pointing out that messages are *not* lost if you choose "ack: client" mode. Instead, if the connection is dropped with unACKed messages outstanding on it, the unACKed messages are requeued and redelivered to the next consumer that comes along.<br>
<br>
This redelivery behaviour, in conjunction with TCP's built-in window management, means that a crude form of flow control is simply to stop reading from the socket. When the buffers fill up at each end, the RabbitMQ server will notice, and will stop feeding the busy connection.<br>
</blockquote></div><div><br></div></div><div>What flow control mechanisms are available when using AMQP directly (not via the STOMP adapter)? When working with many small messages, depending on the TCP buffer does not seem ideal, as many hundreds or thousands of messages can get queued up before RabbitMQ realizes the consumer is busy. </div>
<div><br></div><div>With no_ack=false, will RabbitMQ send a consumer new messages before previous messages are acknowledged?</div><div><br></div><font color="#888888"><div> Aman</div></font></div>
</div><br></div>