View Source Edeliver.Relup.Instructions.SuspendRanchAcceptors (edeliver v1.9.2)
This upgrade instruction suspends the ranch acceptors
to avoid that new connections will be accepted. It will be inserted right after the "point of no return". When the upgrade is done, the
Edeliver.Relup.Instructions.ResumeRanchAcceptors
instruction reenables the acceptors again. To make sure that the ranch acceptors are found, use this instruction after the
Edeliver.Relup.Instructions.CheckRanchAcceptors
instruction which will abort the upgrade if the acceptors cannot be found. Because real suspending of ranch acceptors is not possible because ranch acceptors do not handle sys messages, they are actually terminated. Unfortunately the ranch acceptor supervisor cannot be suspended in addition to avoid starting new acceptors, because supervisors can't be suspended because the supervision tree is used to find processes which uses callback modules. Since no acceptors are started dynamically this can be ignored. Use the
Edeliver.Relup.Instructions.ResumeRanchAcceptors
instruction at the end of your instructions list to re-enable accepting tcp connection when the upgrade is done.
Link to this section Summary
Functions
Returns name of the application. This name is taken as argument
for the run/1 function and is required to access the acceptor processes
through the supervision tree
Calls the run/1 function of this module
This module requires the Edeliver.Relup.Instructions.CheckRanchAcceptors module
which must be loaded before this instruction for upgrades and unload after this
instruction for downgrades.
Appends this instruction to the instructions after the "point of no return" but before any instruction which loads or unloads new code, (re-)starts or stops any running processes, or (re-)starts or stops any application or the emulator.
Callback implementation for Edeliver.Relup.Instruction.modify_relup/2.
Suspends all ranch acceptors to avoid handling new requests / connections during the upgrade. Because suspending of ranch acceptors is not possible they are terminated. In addition the ranch acceptor supervisor is suspended to avoid starting new acceptors.
Link to this section Functions
@spec arguments( %Edeliver.Relup.Instructions{ changed_modules: term(), down_instructions: term(), down_version: term(), up_instructions: term(), up_version: term() }, Edeliver.Relup.Config.t() ) :: term()
Returns name of the application. This name is taken as argument
for the run/1 function and is required to access the acceptor processes
through the supervision tree
@spec call_this(arguments :: [term()]) :: Instruction.instruction() | Instruction.instructions()
Calls the run/1 function of this module
from the relup file during hot code upgrade
@spec dependencies() :: [instruction_module :: atom()]
@spec dependencies() :: [Edeliver.Relup.Instructions.CheckRanchAcceptors]
This module requires the Edeliver.Relup.Instructions.CheckRanchAcceptors module
which must be loaded before this instruction for upgrades and unload after this
instruction for downgrades.
@spec insert_where() :: Instruction.insert_fun()
Appends this instruction to the instructions after the "point of no return" but before any instruction which loads or unloads new code, (re-)starts or stops any running processes, or (re-)starts or stops any application or the emulator.
Callback implementation for Edeliver.Relup.Instruction.modify_relup/2.
@spec run(otp_application_name :: atom()) :: :ok
Suspends all ranch acceptors to avoid handling new requests / connections during the upgrade. Because suspending of ranch acceptors is not possible they are terminated. In addition the ranch acceptor supervisor is suspended to avoid starting new acceptors.