[erlang-questions] System limit bringing down rex and the VM

[Chandru]

On 8 September 2010 19:12, Musumeci, Antonio S <
Antonio.Musumeci@REDACTED> wrote:

> And what if the needs are dynamic in nature? Or if I *want* the limit and
> need to take some action when it occurs? There is no technical reason not to
> handle the error. It's purely a design decision or something that was
> overlooked.
>
Limits are for limiting. Crashing is not an appropriate action to a definite
> and controllable problem. If you didn't care about whether or not something
> crashed there would be no limits at all. This is no different from a whole
> OS crashing because some process consumed too much memory or file handles.
>

This is the way erlang has been designed. If it hits a system limit, it
crashes. Simply because it cannot cope. By not crashing, and returning error
codes, you get defensive programming which makes programs harder to
read/write/test. As far as BEAM is concerned, the ability to spawn a process
is a fundamental requirement. If that cannot be met, all bets are off. I
suspect the resource exhaustion is being caused by your own code, and a bit
of overload control, coupled with configuration of BEAM as pointed out by
others should solve the problem.


> I shouldn't have to build my own spawn wrapper to keep track of the number
> of processes. The VM already does this. Besides, this problem couldn't be
> fully addressed that way.


You don't have to. I suspect you need to do some sort of load regulation in
your system.


> This is caused by mnesia reacting to some event causing mnesia_recover to
> send a rpc. I'm not in control of that.
>

The error message you see about mnesia_recover is the "effect", not the
"cause".

cheers
Chandru