[rabbitmq-discuss] ACK modes in the STOMP adapter

[Aman Gupta]

>
> At present, no, there's no explicit flow control mechanism.
>
> 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.
>
> 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.
>
> 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.
>

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.

With no_ack=false, will RabbitMQ send a consumer new messages before
previous messages are acknowledged?

  Aman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080729/fb2ecaec/attachment.htm