The adapter lifecycle
Table of Contents
1. Summary
The service tracks each adapter in one of five states: announced, ready,
serving, stale and rejected. The messages of
An adapter and the service meet at four messages cause every change. The service needs no other knowledge
of how the adapter runs.
2. Detail
Figure 1: The states of an adapter as the service sees it.
Source: market_data_adapter_states.puml. Regenerate with
plantuml -tpng doc/knowledge/architecture/market_data_adapter_states.puml.
| State | Meaning | Entered by |
|---|---|---|
announced |
The adapter has sent its provider and universe. | Announce |
ready |
The universe agrees with the catalogue and no demand is set. | Universe check |
serving |
The adapter holds a non-empty demand set. | An accepted demand reply |
stale |
The adapter missed its heartbeat. | Heartbeat timeout |
rejected |
The provider is unknown to the catalogue. | Universe check |
A stale adapter keeps its routes. The service shows the gap in the source's
screen and in quality counters. When the heartbeat returns, the service sends the
demand set again.
2.1. What the adapter does inside these states
A live adapter manages its vendor session: connect, authenticate, resubscribe and reconnect. The simulator starts and stops generators. Both are private to the adapter. See A live and a simulated source differ only inside the adapter.
3. See also
- Market Data Architecture — the structure note that orders this cluster.
- An adapter and the service meet at four messages — completes: the messages that cause the changes.
- Demand drives what an adapter publishes — completes: the set sent on the move to
serving.