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

[Anthony Molinaro]

On Thu, Sep 09, 2010 at 09:33:49AM -0400, Musumeci, Antonio S wrote:
> So long as work around behaviors that force my hand. If the system is intended to be robust, to deal with major issues by crashing and letting others clean up... then why doesn't rpc work the same way? Or perhaps the supervisor? Why is the crashing behavior left up to a side effect rather than explicit? It hardly seems like this was purposefully designed this way. There are other conditions which cause rpc to be unable to fulfill the request. I don't see why process limits are different. When I run out of file descriptors in some of my software they don't crash... they attempt to prioritize the resources I do have and free up things if possible. Running out of FDs is not the end of the world, neither is running out of processes. Hell, in C you can attempt to recover from a sigsegv or worse. In general it may be pointless but in some situations maybe not. It's for me to decide.

Are you running heart?

http://www.erlang.org/doc/man/heart.html

With heart you have an external process which restarts the vm if it crashes.
Now of course I've had buggy linked-in drivers crash the vm, and cause it
to restart over and over and over again, but it does seem to keep it running.

So there is still a way to crash and let others cleanup.  It's not always
what you want, but when it happens likely means a bug in your system
somewhere.

I see no problem with you starting a minimal vm and spawning the rex process
yourself so you can capture errors and try to deal with them.  You've stated
this can be done, so why not just do it?

Sincerely,

-Anthony

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <anthonym@REDACTED>