<div dir="ltr">I just wanted to follow up on this question.<div><br></div><div style>This morning I came in to find this situation:</div><div style><img src="cid:ii_13c72176182a21fc" alt="Inline image 1" width="590" height="18"><br>
</div><div style><br></div><div style>A partner who seems to be having issues has caused 2.3M messages to be waiting for ACKs.</div><div style><br></div><div style>I'm quite sure that many of these messages should have expired, but are not being deleted because they're waiting ACK. (I'm running RabbitMQ 3.0.1)</div>
<div style><br></div><div style>1) How should a message behave if it's TTL has expired and it's waiting for ACK?</div><div style>2) Is there really not that much interest setting a per-channel prefetch queue limit?</div>
<div style><br></div><div style>Thanks so much!</div><div style><br></div><div style>-Dave</div><div style><br></div><div style><br></div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sat, Jan 12, 2013 at 3:28 PM, Dave Seltzer <span dir="ltr"><<a href="mailto:dseltzer@tveyes.com" target="_blank">dseltzer@tveyes.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"><div>If you're asking me, then I think the answer might be the ability to set a limit on the number of un-acked messages per channel, and then the ability to limit the number of channels per user/vhost.</div>
<div><br></div><div>Perhaps the new Policy framework in RabbitMQ 3.0+ would provide an interesting way to configure this behavior.</div><div><br></div><div>I think that part of the problem is that most of the examples in the ClientAPI documentation don't touch on this issue, so a naive user, who copies and pastes an example, might find themselves with an enormous pre-fetch queue and never even know it. But, even if my users were more conscientious about setting this variable, I think there's still a compelling argument to be made that a broker-administrator should be able to limit it.</div>
<div><br></div><div>Thanks for taking the time to explain the complexity!<br></div><div><br></div><div>-D</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 12, 2013 at 9:34 AM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dave,<br>
<br>
On 10/01/13 13:54, Dave Seltzer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I was wondering if there's a way to set a policy on the broker that<br>
would effectively limit the size of the pre-fetch queue for clients?<br>
</blockquote>
<br>
It is not uncommon for for novice users (and some clients) to forget to ack messages, or accidentally buffer vast quantities of messages in the client.<br>
<br>
We did consider setting basic.qos{prefetch_count=1} as a default, i.e. all channels would be limited like that unless the app issues a basic.qos of its own.<br>
<br>
Unfortunately that a) could break existing apps, and b) significantly reduces throughput.<br>
<br>
As you say, one option would be to make this server configurable. Since we try to keep the number of config settings small, this is really a last resort. Still, it might be worth exploring...<br>
<br>
At what granularity should a prefetch count be configurable?<br>
<br>
a) server<br>
b) user<br>
c) vhost<br>
d) user & vhost<br>
e) peer ip<br>
f) ...<br>
<br>
<br>
Regards,<br>
<br>
Matthias<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><span style="font-size:x-small"><a href="mailto:dseltzer@tveyes.com" target="_blank">Dave Seltzer</a></span></div>
<div><font size="1">Chief Systems Architect</font></div>
<div><font size="1">TVEyes</font></div><div><font size="1"><a href="tel:%28203%29%20254-3600%20x222" value="+12032543600" target="_blank">(203) 254-3600 x222</a></font></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><span style="font-size:x-small"><a href="mailto:dseltzer@tveyes.com" target="_blank">Dave Seltzer</a></span></div><div><font size="1">Chief Systems Architect</font></div>
<div><font size="1">TVEyes</font></div><div><font size="1">(203) 254-3600 x222</font></div>
</div>