View Source ProcessHub.Strategy.Migration.HotSwap (ProcessHub v0.4.0-beta)
The hot swap migration strategy implements the ProcessHub.Strategy.Migration.Base protocol.
It provides a migration strategy where the local process is terminated after the new one is
started on the remote node.
In the following text, we will refer to the process that is being terminated after the migration as the peer process.
Hotswap migration can also handle process state migration when nodes are leaving the cluster. The process states are stored in the local storage and are sent to the remote node before the local process is terminated. This will only work if the node is being shut down gracefully.
The hot swap strategy is useful when we want to ensure that there is no downtime when migrating the child process to the remote node. It also provides a way to ensure that the state of the process is synchronized before terminating the peer process.
To pass the process state to the newly started process on the remote node, the
:handover option must be set to true in the migration strategy configuration, and
necessary messages must be handled in the processes.
Use HotSwap macro to provide the handover callbacks automatically.
If the
:handoveroption is set totrue, the process must implement the necessary callbacks. This can be done by using theProcessHub.Strategy.Migration.HotSwapmacro.use ProcessHub.Strategy.Migration.HotSwapAdditionally, the user can override the
alter_handover_state/1function to modify the state before it is set as the new state for the child process. The function must return the modified state.defmodule MyProcess do use ProcessHub.Strategy.Migration.HotSwap def alter_handover_state(state) do # Modify the state here state end end
Summary
Types
@type t() :: %ProcessHub.Strategy.Migration.HotSwap{ child_migration_timeout: pos_integer(), confirm_handover: boolean(), handover: boolean(), handover_data_wait: pos_integer(), retention: pos_integer() }
Hot-swap migration strategy configuration. Available options:
:retention- An integer value in milliseconds is used to specify how long the peer process should be kept alive after a new child process has been started on the remote node. This option is used to ensure that the peer process has had enough time to perform any cleanup or state synchronization before the local process is terminated. Keep in mind that process will be terminated before the retention time has passed if the peer process has notified the handler process that the state transfer has been handled. The default value is5000.:handover- A boolean value. If set totrue, the processes involved in the migration must handle the following message:{:process_hub, :send_handover_state, receiver_pid, child_id, opts}. This message will be sent to the peer process that will be terminated after the migration. The variablereceiver_pidis the PID of the process who is expecting to receive the message containing the state of the peer process. If the:retentionoption is used, then the peer process has to signal the handler process that the state has been handled; otherwise, the handler will wait until the default retention time has passed. The handler PID is passed in thefromvariable. Theretention_receiverpid can be accessed from theoptsvariable. The default value isfalse.:confirm_handover- A boolean value indicating if the state handover process should be performed synchronously. This option only takes effect if:handoveris turned on. Default value isfalse.:handover_data_wait- An integer value in milliseconds is used to specify how long the handler process should wait for the state of the remote process to be sent to the local node. The default value is3000.:child_migration_timeout- An integer value in milliseconds is used to specify the timeout for single child process migration. If the child process migration does not complete within this time, the migration for this child process will be considered failed but the migration for other child processes will continue. The default value is10000.