Skip to main content

General Questions

What is Ember?​

Ember is the internal name for the Execution Server (ES).

Hardware Requirements​

There are no hardware requirements. As long as ultimate performance is not required, the Execution Server can be launched anywhere a Java process can run.

Running Multiple Ember Instances​

You can run multiple instances of the Execution Server on the same machine using different EMBER_WORK directories. However, we do not recommend doing this in production. Use an Ember Cluster instead. There is some management overhead of running additional instances of the Execution Server.

What Is the Maximum Number of Instruments Supported?​

Most clients trade on 50-500 instruments. However, some clients run Ember on a universe of 500K instruments.

Dynamic List of Instruments​

Ember can detect when new instruments appear in the securities stream, and when existing instruments update.

Ember does not support instrument deletion, meaning, it will not notice deletes. This configuration aligns with most use cases.

Ember does not detect schema changes made to the TimeBase securities stream. For example, adding a custom field to map the primary symbol with an exchange specific symbol format. Restarting the ember service is required to recognize this change.

FIX Gateway Symbology​

When clients send orders to Ember, they have to write against Ember spec.

The Ember FIX Gateway does not have the ability to translate order symbology. Order and market data requests should use Ember's internal symbology--the symbology of securities and market data streams.

Ember does have the ability to translate symbology when connecting out (when sending orders and market data requests to other venues). This is fair and symmetric.

How Does the Algorithm Restore the Trading State After Startup?​

The algorithm is a state machine. Ember restores the trading state by replaying all trading requests and trading events. We do this for all orders, including the ones that were rejected, cancelled, and filled. This happens during a phase called "bootstrap". All messages related to a specific algorithm are replayed back to this algorithm on startup.

For clients who prefer a simpler method of restoring the trading state, we offer a Bootstrap Helper class that consumes all historical messages and, at the end of the bootstrap phase, simply tracks the orders that remained active and their exact state.

There is a process called Journal Compaction that removes old trading history from the Ember journal. If your algorithm wants to know the Positions starting from the beginning of time, you may need to request them from the Ember Order Management System (OMS) during startup.

Historical Orders in Ember Monitor​

Ember Monitor doesn't support queries for historical orders.

Ember Monitor supports the following functionalities:

  • Show all currently active orders.
  • Show the last N (default N = 100) of completed orders for each order source (for example, a FIX client).
  • Search for a specific order by ID (if it's still in the Ember journal).

Ember Monitor can't answer questions like:

  • "Give me all the orders from the past hour."

For historical queries, use Data Warehouses like Amazon Athena.