4.3 Module classy_boot

This module controls the boot sequence of business applications managed by classy. It is based on a concept of run levels and barriers.

Run level is an integer in range ?classy_rl_stopped .. ?classy_rl_ready (where classy_rl_stopped = 0 and classy_rl_ready = 300), corresponding to the “readiness state” of the system. Run levels 0..9 are reserved for classy, which leaves business applications with 290 usable run levels.

Unless the whole BEAM VM or classy application is abruptly stopped, the run level is stepped in an increasing or decreasing arithmetic progression. When classy:start_system/0 function is called for the first time, the system starts at stopped run level (0) and eventually progresses to the ready run level (300). Effect of classy:stop_system/0 is the opposite.

Barriers can be set to temporarily limit the progression of the run level. When a barrier is set at run level N, the system drops level to N (if it was at level M > N, then it will do so by going through M, M - 1, ..., N sequence) and stays there until the barrier is removed. If there are multiple barriers, system waits for the one set at the lowest run level.

The general idea is that initialization of the business logic can be represented as a directed acyclic dependency graph, and each topological level of the DAG can be mapped to a certain run level. Business applications can hook initialization and de-initialization logic to each level using classy:on_run_level/2 function. Initialization hooks can set up barriers that are removed asynchronously (when some subsystem becomes ready). This approach allows to avoid blocking calls that wait for the readiness condition, which can be problematic when the system has to stop or restart before fully ready.

The run levels are split into several ranges:

  1. stopped 0..9. These are reserved for classy’s own initialization logic. Business applications must not use them.
  2. single ?classy_rl_single..99 where ?classy_rl_single = 10. These run levels correspond to initialization of a singleton node.
  3. cluster ?classy_rl_cluster..199 where ?classy_rl_cluster = 100. Boot sequence progresses to this stage when the number of known peers (up or down) is >= n_sites.
  4. quorum ?classy_rl_quorum..299 where ?classy_rl_quorum = 200. Boot sequence progresses to this stage when the number of known connected peers is >= quorum.
  5. ready ?classy_rl_ready = 300. Final run level. The system is fully operational.

WARNING: classy doesn’t check that the boot dependency graph is acyclic and that mapping to run levels is valid, leaving this responsibility to the system designer. There are no safety checks for the barrier levels: setting them improperly can lead to hung boot. The developer can use classy_boot:diagnostics/1 function to troubleshoot the boot state.


JavaScript license information