2008/6/3 Vlad Dumitrescu <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
HI,<br><br><div class="gmail_quote">2008/6/3 Chandru <<a href="mailto:chandrashekhar.mullaparthi@gmail.com" target="_blank">chandrashekhar.mullaparthi@gmail.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
2008/6/3 Sean Hinde <<a href="mailto:sean.hinde@gmail.com" target="_blank">sean.hinde@gmail.com</a>>:<br></div><div class="gmail_quote"><div><div></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">

<div><div></div><div>On 2 Jun 2008, at 14:31, Chandru wrote:<br><br></div></div></div><div class="Ih2E3d">
I respectfully disagree. It is nigh on impossible to predict where there might be some error that leads to a large queue, and this would lead to "defensive programming" where every process has a short max length. This would result in random crashes and loss of data for those uncommon situations in an generally well designed system where there might be a legitimate short term peak in queue lengths.<br>



<br>
We already have a mechanism to restart if a queue grows too large (actually 2 - process_info monitoring, and out of memory !)<br>
<br></div></blockquote></div></div><div class="Ih2E3d"><div><br>I agree it is nearly impossible to predict this -  but what options does a programmer have without this bounded queue facility. <br><br>  1. Introduce message queue monitoring for every process which is potentially long lived, which imho is extra boiler plate code which reduces readability of core functionality. Also there will be different ways of doing it depending on how your process is structured (gen_fsm, gen_server, gen_event, pure erlang...). If all that one does upon detecting this condition is clear the message queue by discarding messages, or terminate the process, wouldn't it be good to have this built-in?<br>


<br>  2. have another process which monitors the entire system - which is not very scalable when you have hundreds of thousands of processes.<br><br>  3. Wait for the system to crash in live and then figure out what happened.<br>


<br></div></div></div></blockquote></div><br>An alternative to the crash-when-queue-is-full solution could be that a user-defined function gets called first. This function should use application-specific knowledge to clean up the queue with the least amount of disturbance for the application. The process should crash only if this cleanup is still not enough or if the function sets a new higher threshold for the queue length. The function could also turn on debug mode so that the reason for the many messages is found as it happens. <br>

</blockquote><div><br>I agree. This would be useful too.<br><br>cheers<br>Chandru<br> <br></div></div>