View Source API Reference ProcessHub v0.7.0

This is the main public API module for the ProcessHub library. It is recommended to use only the functions defined in this module to interact with the ProcessHub library.

Custom events defined as macros.

Defines the list of hooks that can be used to extend the functionality of ProcessHub.

The ProcessHub coordinator module is responsible for coordinating most of the ProcessHub events and work.

The ProcessHub distributed supervisor module is responsible for starting and stopping the child processes distributed across the cluster.

A struct representing an asynchronous operation that can be awaited for results.

The main ProcessHub initializer supervisor module.

Node-level request for starting child processes.

Data structure for post-start processing results.

Node-level request for stopping child processes.

Represents a post-action to be executed after children are started on the target node.

The items queued behind one flush — the core of a group commit.

ProcessHub instances with the same hub_id will automatically form a cluster. The cluster service provides API functions for managing the cluster.

The declared list: a versioned, durable, leader-written list of the children that SHALL exist on a hub.

Boot-time resolution of the declared list: adopts the highest version among the local store and the remote manifest, seeds version 1 from durable registry rows on first enablement, and parks the hub's reconcile when the list is missing while durable evidence says it should exist.

Local persistence of the declared list: the DETS-backed store beside the registry file, the misc-storage read cache, the seeded marker, the park flag, and the hand-off to the remote-manifest shipper. Every stored manifest goes through write/2, so the persist-before-cache order and the seeded marker are maintained in one place.

The dispatcher service provides API functions for dispatching events.

The distributor service provides API functions for distributing child processes.

The hook manager service provides API functions for managing hook dispatching, registration, and lookup.

Logging service for ProcessHub with Drupal-style placeholder-based formatting.

Deferred-migration list and graceful node drain for the migration consent protocol. See ProcessHub.Strategy.Migration.MigrationConsent.

The process registry service provides API functions for managing the process registry.

The registry row's ProcessHub-owned bookkeeping, stored under the reserved metadata key :__process_hub__.

Orphan reconcile: every round converges the cluster toward the hub's declared list (ProcessHub.Service.DeclaredChildren) — it starts declared − observed running anywhere through the normal start path with check_existing: true, and stops running children whose declared entry was removed. The same difference covers a whole-cluster restart and a single-node rejoin; stop knowledge is list absence and never expires.

One orphan reconcile round: takes the declared list as the candidate set, starts the unaccounted remainder, stops undeclared runners, cleans stale rows, and resolves duplicate bindings. A parked list yields no starts and no stops — a lost list must never be mistaken for "nothing declared".

Unified module for distributed operation tracking and execution utilities.

The Ring service provides API functions for managing the hash ring.

The state service provides API functions for managing the state of the hub.

Local storage service. Provides API functions for managing local storage used by ProcessHub for three concerns

Behaviour contract for ProcessHub registry storage backends.

DETS-backed registry storage. Selected via registry_backend: {:dets, opts} on ProcessHub.t().

On-disk DETS file management shared by the DETS-file storage backends (ProcessHub.Service.Storage.Dets and ProcessHub.Service.Storage.DurableEts).

Hybrid registry storage. Selected via registry_backend: {:durable_ets, opts} on ProcessHub.t().

The stored-entry value object shared by every registry storage backend.

ETS-backed registry storage.

The synchronizer service provides API functions for synchronizing process registry data between nodes.

A struct representing the result of starting child processes across multiple nodes.

A struct representing the result of stopping child processes across multiple nodes.

Behaviour for off-cluster declared-list storage.

Filesystem adapter for ProcessHub.Storage.RemoteManifest. Dependency-free.

S3 adapter for ProcessHub.Storage.RemoteManifest, behind the optional :ex_aws_s3 dependency (with :ex_aws and an HTTP client configured per its documentation). Works with any S3-compatible store.

Ships declared-list versions to the configured remote manifest adapter: asynchronously, retried with exponential backoff, coalescing superseded versions so only the newest one is ever in flight. Failures emit the manifest_ship_failed hook and never affect the originating command.

The distribution strategy protocol defines behaviour to identify the nodes which are responsible for a child process.

Provides implementation for distribution behavior using centralized load balancing.

Provides implementation for distribution behaviour using consistent hashing.

Provides implementation for distribution behaviour using consistent hashing.

The autonomous migration strategy implements the ProcessHub.Strategy.Migration.Base protocol.

The migration strategy protocol provides API functions for migrating child processes.

The cold swap migration strategy implements the ProcessHub.Strategy.Migration.Base protocol. It provides a migration strategy where the local process is terminated before starting it on the remote node.

Shared behaviour for migration state handover callbacks.

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 and registered.

Opt-in migration consent, enabled by setting consent_settings on the HotSwap or ColdSwap migration strategy.

Shared migration logic used by both ColdSwap and HotSwap strategies.

The partition tolerance strategy protocol defines the behavior for handling node up and down events in the ProcessHub cluster.

The divergence strategy for partition tolerance is used when the ProcessHub cluster is not concerned with partition failures.

The dynamic quorum strategy provides a dynamic way to handle network partitions in the ProcessHub cluster.

The majority quorum strategy provides automatic partition tolerance that adapts to cluster size.

The static quorum strategy provides partition tolerance through a fixed minimum node count.

The redundancy protocol relies on the HashRing library to distribute processes across the cluster and determine which node should be responsible for a given process by its child_id key.

The replication strategy allows for multiple instances of a process to be started across the cluster. The number of instances is determined by the replication_factor option.

The Singularity strategy starts a single instance of a process and creates no replicas on other nodes. This is the default strategy.

This protocol defines the behavior of a synchronization strategy.

The Gossip synchronization strategy provides a method for spreading information to other nodes within the ProcessHub cluster. It utilizes a gossip protocol to synchronize the process registry across the cluster.

This PubSub synchronization strategy uses the :blockade library to dispatch and handle synchronization events. Each ProcessHub instance has its own event queue that is used to dispatch and handle synchronization events.

Handler for node down events. Processes one or more node failures together to avoid duplicate redistributions. Always operates on a list of removed nodes (even if single).

Handler for the node up event.

Handler for periodic synchronization.

Handler for initializing synchronization.

Utility functions for testing.

Utility module for extracting information from datasets.

Per-key timer bookkeeping over a plain map of key => timer_ref.

A worker process that handles post-startup tasks after the core supervisor tree is initialized.