<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 21, 2014 at 1:06 PM, Kane Kim <span dir="ltr"><<a href="mailto:kane.isturm@gmail.com" target="_blank">kane.isturm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is it ok to have many unacked messages in rabbitmq (millions)?</div></blockquote><div><br></div><div>The real answer is "it depends" but be mindful and understand what it means and what it depends on.</div>
<div><br></div><div>�A message in the unacked state has been delivered to a consumer, but the broker is still maintaining knowledge of it. �That way, if the consumer crashes, and its channel closes, without having sent an ACK, the broker knows to re-queue the message for another delivery attempt. �It does this, because, in the absence of the consumer's ACK, it has no way of knowing the consumer got any useful work done with the consumed message before it perished.</div>
<div><br></div><div>Messages languishing on the broker in the 'unacked' state consume resources. �At the very least memory. �If they were published with persistence requested, or if the broker has paged them to disk under memory pressure, they will also consume disk space. �Finally, there's some small in memory indexing overhead associated with each message as well.</div>
<div><br></div><div>If you let messages build up too long you can get into trouble as your broker runs low on memory or disk resources. �The broker will try to pause publishers to avoid being swamped, but you're still best managing your application in a way that such conditions don't exist for long periods.</div>
<div><br></div><div>If you have *millions* of un-acked messages in queues, I would start to wonder if perhaps your consumers are getting their work done and failing to ACK. �Or perhaps they're working properly and obeying proper ACK discipline, but incoming work is arriving at a rate that outpaces them. �In that case you'd be wise to add more consumers....�</div>
<div><br></div><div>A good general mantra: �"A Happy Rabbit is an Empty" rabbit. �Message brokers will hold messages to buffer against transient spikes in traffic, but they're not intended to be long term stores of persistent data, and shouldn't be treated as such. �If you have a lot of messages piling up in the broker, look at your producer arrival and consumer exit situations to understand what's happening. �It's often a sign that either the ambient conditions of your system have changed (e.g. a flood of new demand due to a surge in work) or something has crashed or backed up...</div>
<div><br></div><div>Knowing the expected and usual queue sizes and whatnot, learned by experience and observation of your system, is a good practice in operationalizing this sort of stuff.</div><div><br></div><div>Best regards,</div>
<div>Jerry</div><div><br></div></div></div></div>