Lack of publisher throttling

[JSteunou]

or certainly me using rabbitmq wrong, but when sending messages (150ko) at a rate slightly over 100/s and 2 clients receiving at the same rate, rabbitmq binaries memory is raising up the sky. In 1 min I can read 4Gb in the processes binaries section.

When sending at 50/s it's ok, staying low < 2MB

I did not find the critical point rate yet, but I found this very strange.

(rmq 3.5.7)

[michaelklishin]

It's not a memory leak but rather lack of flow control internally in the plugin: your consumers cannot keep up with the publishers and RabbitMQ doesn't throttle publishers, it seems.

[michaelklishin]

Actually, this is almost certainly a duplicate of https://github.com/rabbitmq/rabbitmq-web-stomp/issues/40, which talks about resource-driven flow control for Web STOMP connections.

[JSteunou]

I was reading this one https://github.com/rabbitmq/rabbitmq-java-client/issues/19 (not finished yet) because the title is a good match of my issue. But yeah, that's maybe it, I have this issue when consumer is laggy or bad network.

[JSteunou]

One more thing @michaelklishin, is producer throttling can be achieved with queue max length?

[michaelklishin]

@JSteunou effectively, yes, or message TTL. Anything that limits queue growth will help. That said, the unbounded buffer growth problem is applicable to consumers, too, not just queues, and that's a more likely reason here. But nonetheless having a max queue limit will help.

[michaelklishin]

@JSteunou that Java client issue is the same general problem, just in a different context.

[JSteunou]

But I found it weird that people generally speaks of thousands of msg/s when I cannot reach above 100msg/s without seeing this memory issue. And my queues are empty. RMQ manager shows me no delay between in & out. Is the memory grow in the process dedicated to sending over TCP waiting the previous msg to be actually received? In that case how message TTL or queue limit could help?

[michaelklishin]

It could be the number of messages consumed by the plugin but not yet delivered to the client. It's a function of message size and the ingress and egress rate difference. Having a queue length limit or message TTL effectively throttles the publisher (to some extent).

On Tue, Apr 12, 2016 at 6:19 PM, Jérôme Steunou notifications@github.com wrote:

But I found it weird that people generally speaks of thousands of msg/s when I cannot reach above 100msg/s without seeing this memory issue. And my queues are empty. RMQ manager shows me no delay between in & out. Is the memory grow in the process dedicated to sending over TCP waiting the previous msg to be actually received? In that case how message TTL or queue limit could help?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/rabbitmq/rabbitmq-web-stomp/issues/58#issuecomment-208958503

MK

Staff Software Engineer, Pivotal/RabbitMQ

[JSteunou]

ok thanks for the lights @michaelklishin that's really helpful. I already have a throttler tool, I guess it will have one more task to do now :)