evoq_pm_router (evoq v1.30.1)

View Source

Routes events to process manager instances.

Correlates events with process manager instances based on the correlate/2 callback and routes them accordingly.

Correlation Flow

1. Event received 2. Find all PM modules interested in this event type 3. For each PM, call correlate/2 to determine process instance 4. Route to existing instance or start new one

Instances are node-local: with the same process manager on several nodes, each node routes to and stops its own instances only.

Summary

Functions

This node's instance of PMModule for ProcessId.

Register the instance of PMModule for ProcessId.

Register a process manager module.

Route an event to process manager instances.

Route an event to the instances of the named process managers only.

Start the PM router.

Unregister Pid as an instance of PMModule for ProcessId. Only Pid leaves: it left every member of the group, so a second instance for the same process manager and id (a second {start, Id}) stayed alive and unreachable when the first stopped.

Unregister a process manager module.

Functions

get_instance(PMModule, ProcessId)

-spec get_instance(atom(), binary()) -> {ok, pid()} | {error, not_found}.

This node's instance of PMModule for ProcessId.

Process-manager instances are node-local: a node routes an event to its own instance or starts one, never to another node's. pg shows the members of every connected node, so this reads the local ones only; with all of them, the same process manager on two nodes handed events to the other node's instance and a {stop, Id} on one node stopped the other's (evoq#10). pg drops a dead member asynchronously, so a member is only handed out while it is alive: right after an instance crashed the next event for its id got the dead pid and was dead-lettered instead of starting a fresh instance (evoq#9).

register_instance(PMModule, ProcessId, Pid)

-spec register_instance(atom(), binary(), pid()) -> ok.

Register the instance of PMModule for ProcessId.

Keyed by the process manager module, not by event type: two process managers correlating on the same id (an order id, say) keep separate instances and separate state. Keyed by event type they found each other's instance, and one of them handled the other's events.

register_pm(PMModule)

-spec register_pm(atom()) -> ok.

Register a process manager module.

route_event(Event, Metadata)

-spec route_event(map(), map()) -> ok.

Route an event to process manager instances.

route_event(Event, Metadata, PMModules)

-spec route_event(map(), map(), [module()]) -> ok.

Route an event to the instances of the named process managers only.

The store subscription uses it: it routes a store's events only to process managers whose history from that store it has sent, and a late process manager's history to that one alone (evoq #2, #4).

start_link()

-spec start_link() -> {ok, pid()} | {error, term()}.

Start the PM router.

unregister_instance(PMModule, ProcessId, Pid)

-spec unregister_instance(atom(), binary(), pid()) -> ok.

Unregister Pid as an instance of PMModule for ProcessId. Only Pid leaves: it left every member of the group, so a second instance for the same process manager and id (a second {start, Id}) stayed alive and unreachable when the first stopped.

unregister_pm(PMModule)

-spec unregister_pm(atom()) -> ok.

Unregister a process manager module.