11–20 of 30 posts
You know what would be really amazing is if you could restart the Erlgang VM, or load new a VM without interrupting any of the running code modules.
I'm asking because I don't have enough context to know why you want to do what you're asking to do.
Except you can clone the car into a controlled environment, and test the whole procedure, before doing the actual replacing.
I wonder what HN's devops people think about this wrt the current trend of containers and immutable infrastructure. Hot code reloading seems to be directly at odds with the idea of immutable architecture, because essentially the application code becomes state. So your container becomes stateful, instead of swapping out your old appserver container by a new one. What's your opinion? Ditch Docker and put the Erlang VM…
We're using Erlang as the primary language environment for our IoT product for a lot of reasons but one big one is: Hot code loading and a very robust release upgrade environment with a lot of control over the process (including restarting everything inside the VM if that's what we wish to do).
For our product, a digital light switch / dimmer, high uptime guarantees is a very important requirement and Erlang has it all plus many other wonderful features.
Interesting. The hot code reloading functionality in Erlang led me to investigate ruby (my preferred Dev language) a bit more. You can do a hot code load in Ruby using the Kernel#load() call. It won't alter functionality currently on the call stack, but it will change the functionality of everything not on the call stack. With some sympathetic design, you can achieve hot code loading fo high availability in ruby.
$ cat hi.rb
def method
puts "hi"
end
method
load("hello.rb")
method
$ cat hello.rb
def method
puts "hello"
end
$ ruby hi.rb
hi
hello
You know what would be really amazing is if you could restart the Erlgang VM, or load new a VM without interrupting any of the running code modules.
What -exactly- do you want to do when you say you want to restart the Erlang VM? I'm asking because I don't have enough context to know why you want to do what you're asking to do.
This is cool. What type of scenarios could you not afford a few seconds of downtime on a server? For example, why not simply remove a machine from the cluster/nlb and upgrade it, then add it back ...?
Earlier quoted context omitted.
What -exactly- do you want to do when you say you want to restart the Erlang VM? I'm asking because I don't have enough context to know why you want to do what you're asking to do.
I would assume the longer any VM is running the higher the chances of a service degrading. I guess this is mostly due to memory leaks or bit rot. I have no Erlang VM experience, so my comment was geared towards VMs in general.
This is cool. What type of scenarios could you not afford a few seconds of downtime on a server? For example, why not simply remove a machine from the cluster/nlb and upgrade it, then add it back ...?
When your server has several gigs of state. It's VERY useful on a dev server. Instead of waiting several minutes for reload, I just load in new code manually (typically I change only 1-2 files per reload). If something breaks - hey, it's only dev server. Erlangs other feature - almost everything works alone - helps with this. If something breaks, it breaks only in one place, so most of the time I only need to make sm…
Someone wrote a module for elixir that uses inotify (and similar) to -I think- watch .beam files for modification and perform the required hot-reloads automatically.
I would be reluctant to run this in production, and I can see situations (even in development) where this could trigger unwanted code purging and would be disastrous, but it's a pretty neat thing to have and -it seems- a must for Web Dev people.