[erlang-questions] Why (not) hot code loading

Samuel <>
Sun Jun 22 13:16:02 CEST 2014


Some systems I worked (and still work) with use hot code loading in
production for upgrades and hot-patching. I have never found technical
issues in that functionality per-se; that is, I believe is solid and
works as advertised. However it typically implies many side
difficulties which probably fall into your B category.

There are many things to take into account when doing hot upgrades in
production. Apart from the already mentioned issues with changes in
data models and APIs, the effects of purging code are sometimes very
difficult to predict; testing is not easy as the production system
will have a very long living internal state that is somewhat complex
to reproduce in testing environments; etc, etc.

So, in general, if you could avoid production hot code loading in
favour of more predictable ways of upgrading your systems, like
rolling upgrades, it is likely that you can avoid a large class of
issues and technicalities that are hard to solve.

So if I were to advice you against using it it wouldn't be because it
were a crappy feature or I didn't understand it, it is more because,
for most application domains, it buys you very little at a
non-negligible cost. If you manage to find a problem where other
techniques are actually more costly than hot-upgrading your production
systems then you could use it at your advantage.

Best

On 20 June 2014 20:02, zxq9 <> wrote:
> I've never had a situation where I've needed hot code loading, but a project
> that may be a good fit with this feature is looming (and may not be a good fit
> -- I have much to learn about this feature). Nearly all the advice I see on
> this is to avoid it in production, which seems highly ironic, since this
> feature was designed specifically to ease certain cases of production.
>
> The advice against using it mostly comes from tutorials, presentations and
> asides made by various speakers in talks I've seen. I don't have a canonical
> "don't use hot code loading" reference, but I have exactly zero references
> which urge the use of this feature and explain in depth how to integrate it
> with a release cycle.
>
> But someone worked a long time figuring out how to make this a part of the
> runtime, so...
>
> Is this feature:
> A) "Hard" to use because it is far outside the experience of the average Java-
> or web-developer-turned-Erlanger who tends to give talks about Erlang.
> B) "Hard" to use because it is actually hard: a technically complex feature
> for which little scaffolding is available for easy integration.
> C) Actually not very useful.
> D) People have been trained to accept maintenance downtime and believe that
> loadbalancers are the answer to everything?
>
> Most of the best tools I've ever used fell into category (A), so I wonder if
> that is the case with this feature. Some things I've really liked in
> environments like Guile fell into category (B), which was nice because after
> some thorough study something complex but understandable can be abstracted and
> made easy to use. I have a hard time believing that this feature actually
> falls into category (C), feeling it is much more likely that widespread
> acceptable of the (D) view simply obviates much deep thought on the utility of
> it in the first place -- especially since so much focus, even within the
> Erlang community these days, is on the web and not other areas.
>
> Can anyone provide some insight into this? I'd rather get some opinions now
> than spend time getting to the bottom of a relatively untaught feature only to
> find that it wasn't very useful.
>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions



-- 
Samuel



More information about the erlang-questions mailing list