[rabbitmq-discuss] Memory Management Concerns / Questions

[AndyB]

http://www.rabbitmq.com/memory.html

I'm running into some problems that I'm hoping that someone here can
help me with.  Let me first state my setup.  I'm running the latest
release of RabbitMQ on CentOS (64bit) in a clustered configuration
with 2 nodes in my Production environment.  In my development
environment I only have 1 node though.  My code is written in C# and
is using the downloaded SDK from the website.  The memory
configuration value is set to 40% as the default.

I ran into a problem in my Production environment a week ago where
work was building up on my queue faster than my consumers were
processing it.  Unfortunately I wasnt able to perform any debugging or
metrics gathering before the system was recycled or the queue was
purged.  I'm still not exactly sure exactly which happened.  But what
I can tell you is that it looked to me like exceptions were occurring
for both the publishers and consumers and nothing was really
happening.  I have since added more consumers and have not had the
problem occur again.  But this obviously has me concerned.

I am currently in the process of trying to reproduce this problem in
my development environment, but I'm running into some confusing
results.  My test case is to run multiple publishers sending messages
over and over as fast as possible while also have a single consumer
processing those messages with a delay.  The goal is to obviously
force messages to pile up in memory on the node to trigger the memory
alert.  Since I have both publishers and consumers connected, I'm
expecting to see the consumers begin to get some sort of exception
saying that they cant submit anymore work while the consumer continues
to process.  But what I'm actually seeing is that the publishers
continue piling on and the consumer continues to process, but the
machine eventually runs out of disk space and crashes.

Is there anyone that can advise me on what I'm doing wrong or help me
figure out what changes I can make?

Thanks
Andy