[rabbitmq-discuss] Connection.Blocked triggering?

[Tim Watson]

Sorry Gavin, I was getting confused between channel.flow and connection.blocked there. Someone pointed out that you're talking about http://www.rabbitmq.com/connection-blocked.html - duh! I suspect however, that just because you've managed to get a publisher subject to flow control, doesn't necessarily mean that you've actually triggered a resource alarm such that connection.blocked will be sent. Producers can (and do) enter flow control if the broker/queue cannot keep up with publishing rates, but only when a low memory or disk alarm is trigger will the connection.blocked signal be sent.

Hope that makes sense and sorry for misunderstanding the question.

Cheers,
Tim

On 19 Dec 2013, at 08:25, Tim Watson wrote:

> AFAIK Rabbit hasn't sent connection.block to clients for quite some time. Instead, we introduce flow control in the broker through TCP back-pressure (i.e., not reading from producer's sockets). That is why you can see the connection in a flow state in the UI (because server-side flow control is in effect), but no connection.block is delivered to the client.
> 
> Cheers,
> Tim
> 
> On 19 Dec 2013, at 00:05, Gavin M. Roy wrote:
> 
>> At what point should Connection.Block be sent from RabbitMQ to a client application? I am able to see that I am triggering a Flow state in the RabbitMQ management UI but am not seeing any Connection.Block frames delivered to the client.
>> 
>> Thanks in advance,
>> 
>> Gavin
>> 
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131219/f2e49d27/attachment.html>