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

Musumeci, Antonio S Antonio.Musumeci@REDACTED
Thu Sep 9 15:33:49 CEST 2010


I don't see how that analogy is appropriate. If I removed the breaks I expect it not to work. If I remove rpc I expect rpc not to work. If a break pad fails I still expect the other parts of the car to continue working. I can replace the breaking system without replacing the car. If the engine has some problem I'll get a check engine notification... the car won't just shut down.

Besides, if starting it manually is really a no-no then it probably shouldn't have a :start/0 and :stop/0 as shortcuts.

"nothing in erlang which is making it impossible for you to design a robust system."

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.

________________________________
From: Chandru [mailto:chandrashekhar.mullaparthi@REDACTED]
Sent: Thursday, September 09, 2010 9:03 AM
To: Musumeci, Antonio S (Enterprise Infrastructure)
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions] System limit bringing down rex and the VM

On 9 September 2010 13:37, Musumeci, Antonio S <Antonio.Musumeci@REDACTED<mailto:Antonio.Musumeci@REDACTED>> wrote:
 And as I recall if you start erlang in minimal mode and manually start rex it is not part of the primary supervision tree and can therefore be killed. Why doesn't it then force the VM to fail?

This is a bit like saying that if you disconnect the brakes on a car, and then drive it, it doesn't stop when you press the brakes! rex isn't supposed to be started like that in a "real" system.

I think what everyone is trying to tell you is, from what you've written so far, there is nothing in erlang which is making it impossible for you to design a robust system. In other words, you are barking up the wrong tree.

Chandru



More information about the erlang-questions mailing list