[rabbitmq-discuss] Erlang crashes reports

Romary Kremer romary.kremer at gmail.com
Thu Sep 16 10:32:12 BST 2010

We are performing evaluation on rabbitmq message broker, and we  
currently encounter difficulties with release 2.0.0:

- Our application implies 10 000 peers producing messages periodically  
to a unique queue. This queue is listen asynchronously by another peer.
- All peer are written in Java.
- The production rate of a single peer is 4 messages / hour.
- We can simulate a time-consuming task in the consumer callback,  
simulating more or less fast consumer.
- we are using SSL certificate on the broker side to allow the peer to  
authenticate the broker.
	- we have noticed that the use of SSL as dramatic incidence on the  
memory occupied by Rabbitmq process

Since we upgraded to version 2.0.0, we are no longer able to make a  
test scenario running. The symptoms are listed bellow :

on the broker console first, we get the message :

Erlang has closed
Error: unable to connect to node rabbit at murphys: nodedown
- nodes and their ports on murphys: [{rabbitmqctl22609,42767}]
- current node: rabbitmqctl22609 at murphys
- current node home dir: /var/lib/rabbitmq
- current node cookie hash: qu0gh1hg7j7LKyzK0GLk+A==

we have kept the erl_crash.dump in case, but since i's about 200 MB  I  
cannot do nothing to send it to you.
Maybe some one can give us some hints or some indicators to look out  
in the dump to help diagnostics, but we are not Erlang fluent !

What we know for sure is that the crash happens while the 10 000  
connections are established, at the beginning of the test.
We have monitored the  number of connections established and the  
crashes happens always around 4500 - 5000 connections, but never the  
same exact number.
We also tried with and without SSL but this does not help at all (same  

On the client side, our application registers a ShutdownListener to  
implement a connection retry logic upon shutdown.
The retries always failed with the error : connection refused.

here are some figures we gathered during the test start up about the  
maximum number of connection established before it crashes

- with SSL : 5404, 4493, 4399

- without SSL : 4673
we dont think that the problem is about file descriptors since we  
haven't changed anything in the configuration when we upgraded to 2.0.0.
The same test used to run successfully on previous version of the  
broker (1.7.2, and 1.8.1).
Moreover, the rabbit_status plugin tells us we have enough file  
descriptors as well as erlang processes
	- file descriptors (used / available)= 34 / 65535
	- elrang processes (used / available)= 160 / 1 000 000
	- memory (used / available)= 40 MB / 1609 MB

We haven't try the 2.1.0 yet because we would like to have your  
feedback about this issue before.

We would appreciate your feedbacks on that point before we migrate to  
release 2.1.0.

Best regards,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100916/6a8bd3bb/attachment-0001.htm>

More information about the rabbitmq-discuss mailing list