[rabbitmq-discuss] RabbitMQ Flow Control Behavior Questions

[Simon MacMullen]

On 08/05/13 20:05, Viral Shah wrote:
> Hi,
>       I am using  3.0.4 Java client library/RabbitMQ server and have
> some questions about RabbitMQ flow control behavior.
>
> 1. What is the recommended way of handling/detecting flow control
> invocations on the client side? Is it possible to detect that flow
> control has been invoked on the RabbitMQ server by adding FlowListener
> or any other method? Is it possible to detect that the connection is
> blocked on the client side thru the Java client library or by using some
> workaround so that we can stop sending messages and not get the threads
> stuck in some RabbitMQ method call until the server comes out of flow
> control (which may take longer in some cases).

I'm afraid there isn't one at the moment. The FlowListener interface 
allows the client to determine if the server has sent channel.flow{}. 
But we haven't had the server do that for many releases now 
(channel.flow doesn't work very well).

We are looking at how we can expose the memory / disc alarm state to the 
client in a future release; hopefully it might be in 3.2.

> 2. Channel.close() method does not take a timeout value and the thread
> remains blocked in case the server is under flow control. Is there a
> reason for not having a timeout in the channel close method? If I use
> Connection.close() then it does take a timeout value. Is there a list of
> methods that get blocked during flow control and which ones are not
> affected.

Everything gets blocked *once the connection has published something*.

Connection.close() can take a timeout since there's something the client 
can do unilaterally when the timeout occurs (close the socket). But the 
client can't really do anything in an AMQP sense (including closing a 
channel) if the server is not cooperating.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, Pivotal