←back to thread

268 points lawik | 1 comments | | HN request time: 0.203s | source
Show context
throwaway81523 ◴[] No.42189286[source]
You have to be very very very careful when preparing relups. The alternative on Linux is to launch an entire new server on the same machine, then transfer the session data and the open sockets to it through IPC. I once asked Joe Armstrong whether this was as good as relups and why Erlang went the relup route. I don't remember the exact words and don't want to misquote him, but he basically said it was fine, and Erlang went with relups and hot patching because transferring connections (I guess they would have been hardware interfaces rather than sockets) wasn't possible when they designed the hot patch system.

Hot patching is a bit unsatisfying because you are still running the same VM afterwards. WIth socket migration you can launch a new VM if you want to upgrade your Erlang version. I don't know of a way to do it with existing software, but in principle using something like HAProxy with suitable extensions, it should be possible to even migrate connections across machines.

replies(2): >>42189408 #>>42242565 #
1. throwaway81523 ◴[] No.42242565[source]
Self-followup/correction to avoid misattributing something to Joe that I'm not sure he said. I don't remember him specifically saying there were technical obstacles to migrating connections from one BEAM to another. My main question to him was whether socket migration (such as with SCM_RIGHTS messages on Linux) was a viable alternative to relups. I expected him to say relups were better because [whatever] but instead he said migration was perfectly fine. I do think starting a new BEAM in such situations fits fine with the Erlang spirit of restarting crashed processes so that you start in a known state, rather than trying to recover inside the process.