<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/12/30 sandeep kumar <span dir="ltr"><<a href="mailto:sandy.sandeeep@gmail.com" target="_blank">sandy.sandeeep@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div>where are the published messages are getting store when connections to queue are in blocked state</div></blockquote><div><br></div><div>When RabbitMQ blocks a publisher, it stops reading from the socket. So, some amount of in flight</div>

<div>data will be stored in OS caches. Once those fill up, publishing operations should block (at least with</div><div>most clients).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div>how to handle this kind of scenario gracefully</div></blockquote></div><br><div>Allow RabbitMQ use more RAM, add more consumers so that they drain queues</div><div>and implement a feature in the client (similar to a write-ahead log) where messages can go before being</div>

<div>published. You can also monitor message rates and server state over HTTP API and throttle</div><div>your publishers using app-specific rules.</div><div><br></div><div>See also <a href="http://www.rabbitmq.com/connection-blocked.html">http://www.rabbitmq.com/connection-blocked.html</a></div>

-- <br>MK<br><br><a href="http://github.com/michaelklishin" target="_blank">http://github.com/michaelklishin</a><br><a href="http://twitter.com/michaelklishin" target="_blank">http://twitter.com/michaelklishin</a><br>
</div></div>