<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:10pt"><div>John,<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">> When I run your test, many of the publishers and consumers die because they can't contact the RabbitMQ broker, or can't connect to it in time. This is not surprising, since a small VM with over 1,000 active processes will run very slowly. The failing processes die with messages like "Cannot connect to localhost:5672" and "Opening socket: Connection timed out" and so on.<br><br>Did you use the latest amqp_consumer.c that i sent in my previous email? it re-connects instead of exits in case of connection failure.<br><span><a target="_blank"
href="http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-March/012099.html">http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-March/012099.html</a></span><br>However, you still need run it on a more powerful machine. the broker crash happens when 1000 consumers start consuming messages simultaneously. To to that, you need to have all publishers running at the same time also. Otherwise, if messages in 1000 queues are published sequentially, some consumers will finish consuming 3000 messages before others start. the machine i used for testing has 16 GB memory and 8 cpu. i did not see any publisher got timeout.<br><br>> Although these processes were temporarily unable to connect to the RabbitMQ broker, the broker itself seems to behave properly; it processes messages from and to the subset of publishers and consumers that were able to get through the initial connection storm. It had nothing unusual in its
log.<br><br>as mentioned above, this is because you did not get all consumers to start simultaneously. <br><br>> Could you confirm that this is NOT the failure mode you saw? And how did you know that the RabbitMQ broker had crashed? Did the process go away? Or was it impossible to contact it later on? And how did you try to contact it?<br><br>When it crashed, "ps auxww | grep beam" did not show the broker process running. "rabbmitmqctl list_queues" failed to connect.<br>"telnet localhost 5672" failed. <br><br>-alex<br></div></div>
</div></body></html>