Hi Ben,<br><br><div class="gmail_quote">2009/1/15 Ben Hood <span dir="ltr"><<a href="mailto:0x6e6562@gmail.com">0x6e6562@gmail.com</a>></span><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">> * And if you did a sys:get_status(Pid) on the gen_server, you will copying<br>
> the entire message queue just to view it...<br>
> * Crash reports will be MUCH bigger.<br>
<br>
</div>Sure - transferring the mailbox to process memory does make reading<br>
the state of the process much more heavyweight.<br>
<br>
So it would be a good idea to try to avoid this standard calls.<br>
<br>
However, I still think the benefit of avoiding the scan outweighs<br>
these disadvantages in our particular use case. Previously, we used an<br>
intermediate process as a buffering proxy to solve this problem, but<br>
modifying gen_server seems less intrusive from an API perspective, and<br>
it means that we have one less moving part.<br>
<br>
</blockquote></div><br>I agree. If you are brave enough to have your own version of gen_server, may be you can have your message queue in an ordered_set ets table, instead of a queue. That way, you still keep the message queue in a separate area, and get all the power of ets. Will work better when you have large message queues to deal with.<br>
<br>Is there no way you can throttle your clients before they send a message to the server process? That would make your life a lot easier.<br><br>cheers<br>Chandru<br><br>