[rabbitmq-discuss] RabbitMQ Test case - Possible Memory Leak problem

[Matthew Sackman]

Hi,

On Tue, Jan 11, 2011 at 12:44:54PM +0100, Crisoforo Seccia wrote:
> . Am I adopting a very strange test case which is not well handled by
> RabbitMQ?

Not really, no. However, there are problems with RabbitMQ under Windows,
and you may have to do some tweaking of the configuration. The fact that
you crashed on an eheap allocation suggests that Rabbit tried to
allocate memory that Windows refused it.
http://www.rabbitmq.com/extensions.html#memsup

Rabbit by default assumes that it's the only application running on a
machine, and thus it can expect to be allocated all memory. You may
wish, as suggested in the above page, to try reducing the
vm_memory_high_watermark and repeat the tests.

> . Is there any connection with the solved bug described in the RabbitMQ 2.2
> release notes (“fix memory leak when long-running channels consume and
> cancel on many queues”)?

Nope - that bug would have likely taken months of constant tripping to
actually result in any sizable memory leak.

> . How does RabbitMQ handle message flooding? As stated in ActiveMQ official
> page, the flow control, in the current version means that: “if the broker
> detects that the memory limit for the destination, or the temp- or
> file-store limits for the broker, have been exceeded, then the flow of
> messages can be slowed down. The producer will be either blocked until
> resources are available or will receive a JMSException”.

Again, the above link will explain it all, but in short, Rabbit uses TCP
back pressure to prevent producers flooding it with too many messages.
Ultimately, you're always limited by the rate at which you can get rid
of messages - whether to clients or to disk. In effect, RAM just acts as
a huge (hopefully!) buffer.

Matthew