Горячая загрузка и обновление кода

Erlang's hot code loading is a standout feature! It lets you update a running application's code without stopping it. Imagine changing parts of a website's backend while it's actively serving users, without any downtime!

This capability is crucial for systems that need to run continuously, like telecommunications switches or large-scale distributed services. It ensures maximum uptime and service availability.

The Erlang Virtual Machine (BEAM) manages code modules in a unique way. For each module, it can keep two versions loaded in memory: an 'old' version and a 'new' version.

• When a process starts, it runs the 'new' version of the code.
• If you reload a module, new calls to its functions will use the very latest 'new' version.
• However, existing processes continue to execute the code they were loaded with until they make a call to a function in the *reloaded* module or are explicitly told to change.

You can interactively reload a module in the Erlang shell. The l(Module) function (short for 'load') compiles and loads the latest version of a module from the code path.

Let's see a quick example. We'll define a simple math module, then change a function and reload it.

First, create my_math.erl:

Then, in the Erlang shell, compile it with c(my_math). Call my_math:add(1, 2). Now, *change* the add/2 function in the file to X + Y + 10. Save. Run l(my_math) and call my_math:add(1, 2) again. Notice the new result!

Simple reloading works for purely functional changes (like our my_math example). But what if a running process, especially an OTP behavior like a GenServer, holds internal state that changes its structure?

If you just reload the code, the running GenServer still holds its old state format. The new code won't know how to interpret it, leading to crashes. We need a way to 'transform' the old state into the new state.

OTP behaviors provide a special callback function called code_change/3. This function is designed precisely for handling state migration during a hot code upgrade.

When you tell a running OTP process to upgrade its code, Erlang will call this function in the *new* version of the module. It's your chance to convert the process's old internal state to the new format.

The signature for code_change in a GenServer looks like this:

code_change(OldVsn, State, Extra) -> {ok, NewState}

• OldVsn: The version of the code *being upgraded from*.
• State: The current internal state of the process (in the old format).
• Extra: Additional arguments, often unused.
• You must return {ok, NewState}, where NewState is the transformed state in the new format.

Let's imagine a GenServer that stores a simple counter as an integer. We want to upgrade it to store the counter as a map #{value => integer()}.

The code_change/3 function will receive the old integer state and return a new map state. This ensures the GenServer continues running smoothly with the updated code and state structure.

Here's a simplified example of how code_change/3 would look in my_counter_v2. If our old state was just an integer (e.g., 10), and our new state needs to be #{value => 10}, the conversion is straightforward:

This transformation is key to seamless upgrades.

Hot code loading is powerful, but requires careful planning:

• Test Thoroughly: Always test your upgrade paths in a staging environment before deploying to production.
• Backward Compatibility: Design code_change/3 to handle multiple previous versions if necessary.
• Small, Incremental Changes: Avoid massive changes in state structure in a single upgrade. Break them into smaller, manageable steps.
• Release Handling: In production, hot code upgrades are typically managed by 'release handlers' (like release_handler in OTP applications), which automate the process of loading new code and coordinating state changes across multiple processes and nodes.

You've learned about Erlang's hot code loading and how it handles state changes. Which of the following statements about Erlang's code_change/3 callback are TRUE?

In this lesson, we explored Erlang's powerful hot code loading feature, which allows applications to be upgraded without downtime. We learned:

• Erlang can keep 'old' and 'new' versions of modules loaded.
• Simple code changes can be reloaded with l(Module).
• For stateful processes like GenServers, the code_change/3 callback is essential for transforming a process's internal state when the code structure changes.
• Careful planning and testing are vital for successful hot code upgrades.

This unique capability is a cornerstone of Erlang's fault-tolerant and highly available systems!