<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 style>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 style>Thanks for taking the time to explain the complexity!<br></div><div style><br></div><div style>-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<br>
</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>