[rabbitmq-discuss] MulticastMain Java client causes Erlang error eheap_alloc: Cannot allocate 467078560 bytes of memory (of type "heap") (with RabbitMQ 1.7.1)

[Matthias Radestock]

John,

John Apps wrote:
> I have installed 1.7.1 in a new directory, recompiled the Java client 
> and tried this test again.
> 
> This is the contents of rabbitmq.config
> [
>   {rabbit, [{vm_memory_high_watermark, 3}]},
>   {rabbit, [{memory_alarms, true}]},
>   {mnesia, [{dump_log_write_threshold, 1000}]},
>   {rabbit, []}
> ].
> I have tried various options with the above vm_memory_high_watermark, 
> e.g., .4, .6 and so forth, the 3 above being from the last try. Perhaps 
> there more options that I missed? It would not surprise me.

"3" would mean 300% of system memory, which is probably not what you 
want. I'd stick with the default of "0.4" or lower. I also recommend 
checking what limit is being set by looking in the rabbit.log file for 
the line "Memory limit is set to ...", and to watch out for any memory 
related log messages in general while running your tests.

> Running the MulticastMain (Java) test against RabbitMQ with the 
> parameters shown, leads to an Erlang crash after some time.
> The data below is from a Windows 7 X64 machine running JDK 6 X64.
> 
> "Cannot allocate 467078560 bytes" is the error message.
> 
> C:\AMQP\RabbitMQ\rabbitmq-java-client-1.7.1\test\src>java -server ^
> com.rabbitmq.examples.MulticastMain ^
> -hlocalhost -p5672 -tdirect -eex1 -i10 -m1024 ^
> -n1024 -q20 -r1000 -s100 -x1 -y1

That actually exposes an area of uncertainty in the AMQP spec: At what 
point do transactional acks affect qos? At the time the ack is received 
by the server, or at the time the commit is received? RabbitMQ currently 
takes the latter view, which means with the above settings the consumer 
will not receive more than 20 messages. I have filed a bug to figure out 
whether that's the correct answer.

Anyway, let that not distract us from figuring out why rabbit runs out 
of memory for you... I tried a slightly modified version of the above, 
removing the rate limit and increasing the size to 1000, in order to put 
the server under memory pressure sooner (since at a rate limit of 1000 
and a message size of 100 it would have take several hours). That did 
cause the memory alarms to go off and the producer to be throttled. What 
do you see on your machine when running with these settings?


Regards,

Matthias.