
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>I once made an experimental version of plain_fsm which could enforce a message queue limit.</div><div><br></div><div><a href="http://erlang.org/pipermail/erlang-questions/2008-June/035571.html">http://erlang.org/pipermail/erlang-questions/2008-June/035571.html</a></div><div><br></div><div>I don't think I ever checked it in, but I remember that it wasn't terribly hard to implement.</div><div><br></div><div>Plain_fsm itself nowadays lives at: <a href="http://github.com/esl/plain_fsm">http://github.com/esl/plain_fsm</a></div><div><br></div><div>BR,</div><div>Ulf</div><br><div><div>On 15 Jun 2011, at 18:02, Mihai Balea wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi all,<br><br>Was reading the "discarding signals" thread and thought that maybe a better approach to handling this condition would be to kill the process if the mailbox exceeds a certain size.<br>It seems to me that it would be a cleaner approach than flushing the mailbox and attempting to recover and it also fits better with Erlang's "let it crash" philosophy.<br><br>Basically, the way I see it, we'd have this implemented at system level. One could set a flag, similar to, say, fullsweep_after - either per process or system wide. Default could be infinity, which reverts to the current behavior.<br><br>Any thoughts on this? Any technical or philosophical arguments, pro or contra?<br><br>For the record, I do believe that one should try as hard as possible to avoid getting into this situation to begin with, but occasionally it happens and it is one of Erlang's more spectacular failure modes.<br><br>Cheers,<br>Mihai<br><br><br><blockquote type="cite"><blockquote type="cite">If we are talking about an overloaded system that, for any reason, cannot tell the sender to reduce the traffic, then probably the only way to avoid a system crash is to discard the messages and notify the operators (raise an alarm, write event log, etc.) about this. So the discard shall be very quick as we are already overloaded. Do we have something for that?<br></blockquote></blockquote><br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></div></blockquote></div><br><div>

<div>Ulf Wiger, CTO, Erlang Solutions, Ltd.</div><div><a href="http://erlang-solutions.com">http://erlang-solutions.com</a></div><div><br></div><br class="Apple-interchange-newline">

</div>

<br></body></html>