Understand and inspect Broker Manager

Where the relay fits#

The AMM API owns application requests and sessions. Broker Manager can own a shared upstream broker connection and relay its operations and events to API clients. The Relay screen monitors that layer. It is separate from the REST catalogue and from remote research workers.

A shared upstream connection can serve several API leases. This avoids creating unnecessary competing account logins, particularly for providers with session restrictions. Closing one chart is not a reason to kill a shared Broker Manager process that may serve other active sessions.

Historical backtests and optimizations do not execute through a live-broker relay. A relay outage and a failed historical engine run require different diagnoses.

Check the layers in order#

1. In Settings → Server connection, test the API and inspect WebSocket status.
2. Inspect the configured relay connection. The API can be healthy while the relay is unavailable.
3. Open Relay and inspect shared connections, leases, connected clients and recent activity exposed by that installation.
4. In Brokers & feeds, inspect the actual provider/account connection and any provider error.
5. Confirm that current quotes, reconciled positions and working orders reach the specific chart or strategy you are investigating.

Connection counts are operational state, not a target number to maximize. One shared connection with several leases can be expected. Two similarly named accounts can legitimately use separate connections because their environment or credentials differ.

Read a provider failure#

Read the precise layer and message. An API HTTP error, relay socket disconnect, upstream authentication rejection, missing account permission and missing exchange-data entitlement need different fixes.

The manager selects an explicit provider implementation. Some data-only paths, including Massive, go directly from the API to their data provider rather than through Broker Manager. Their absence from relay activity does not prove that historical or live data is broken. Use the current provider matrix and provider guide.

Rithmic sessions also depend on the selected system, login permissions and app-name whitelist. IB depends on the intended Gateway/TWS account and permissions. A reconnect cannot create a missing provider entitlement.

History pacing and apparent delays#

Historical requests can be paced to remain within upstream limits. Many charts warming at once can take longer than a single live quote. Wait for actual completion and inspect the layer that failed rather than clicking reconnect repeatedly.

A current quote and a populated historical chart are separate checks. Some feeds provide one without the other, or require different subscriptions. Depth additionally needs its own capability and continuity.

Restart with an operational plan#

Before a planned restart, identify every session and client served by that process, whether it can recover safely, and any outstanding orders. Use the supported stop/start procedure for your installation, preserve its configured data and logs, and reconcile after reconnecting.

Do not reset simulation state, delete credentials, clear account history or overwrite broker configuration as a general connectivity fix. Do not stop a development or shared service merely because another profile has a port conflict. An administrator should confirm exact process identity and dependent clients.

After restart, inspect actual broker positions and working orders, recovery status, feed freshness and ownership. A green service indicator proves reachability; it does not prove every strategy has resumed correctly.