<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial">Hi Michael,<div><br></div><div>Thanks for your response very much!</div><div><pre>There indeed were some RAM alarms logged while no disk alarm. The RAM alarms were raised after message accumulate for a long time. </pre><pre>It should be the result, not the reason, right?(before the alarms raised, consumers could not receive message already) </pre><pre>What I can saw at that time was that all consumer threads could not receive message from rabbitmq and gdb tell me they were blocked in tcp receive function.</pre><pre>The connection usage currently is not very well and we will enhance it later. What I confused is the blocking of consumer(as you said, they should not be blocked). The reason  is still uncertain.</pre></div><div><br></div><div><pre>At 2014-04-25 19:58:36,"Michael Klishin" <mklishin@gopivotal.com> wrote:
>
>Resource-based flow control should only block publishers. Re-creating connections
>won¡¯t help: every publishing connection will be blocked. Consumers should not
>be blocked but nearly running out of disk space sounds alarming and can prevent
>RabbitMQ from moving messages to disk or very heavy OS paging .
>
>What¡¯s in RabbitMQ log? There should be disk and RAM alarms logged. rabbitmqctl status
>indicates disk limit alarm should be on.</pre><pre><br></pre><pre>>--  
>MK  
>
>Software Engineer, Pivotal/RabbitMQ
</pre></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>