/
Postponed FIXEdge initialization (Hot/Warm activation modes)

Postponed FIXEdge initialization (Hot/Warm activation modes)

This feature is available starting FIXEdge version 7.1.0

Hot/Warm activation mode is a FIXEdge runtime mode that allows to postpone FIXEdge initialization of the Core Services:

  • FIX Engine (Antenna)

  • Schedules

  • Business layer including BL handlers

  • Transport Adapters

Other FIXEdge components like Admin REST API server, H2 configuration service are initialized as usual and can be utilized to switch between modes.

Upon switching to Hot mode, the following actions are taken by FIXEdge:

  1. FIX Engine (Antenna) session configuration is read from the properties file(s), configuration service (for example H2) and applied. Application of the configuration ends up in creating/starting/scheduling of the FIX Sessions.

  2. Starting FIX Sessions schedules. 

  3. Loading of Business Rules, Business Rules handlers. 

  4. Loading of the Transport Adapters as configured.

FIXEdge may start in the following activation modes:

  • Hot - the usual activation mode, FIXEdge starts and proceeds with initialization, starting FIX sessions, handlers, TAs.

  • Warm - FIXEdge starts, initializes everything except for the Core Services. Admin REST API and configuration services are started, but it is not possible to create/connect any sessions, start TAs, apply Business Rules.

  • TryLock - On startup FIXEdge tries to lock a file. If lock is obtained, FIXEdge switches itself into a Hot mode (proceeds with initialization of the Core Services). Otherwise, FIXEdge stays in the Warm mode until the lock is obtained. 

  • TryHearbeat - On startup FIXEdge tries to lock a file. If lock is obtained, FIXEdge reads a timestamp of the last heartbeat, written to the file by another instance. If the heartbeat timestamp is older than the configured delay, FIXEdge resides in Warm mode until instructed to become Hot. Otherwise, FIXEdge activates in Hot mode. If the last heartbeat timestamp cannot be parsed, FIXEdge resides in the Warm mode.

Admin REST API provides two URLs for monitoring and controlling of the activation mode:

  • GET /service/activationmode - replies with the current activation mode status and mode name. For example: 

    {"mode":"Hot","name":"TryLock"}

  • PUT /service/activationmode/hot - executing an empty PUT request to this URL will override the current mode with Hot.

For configuration details please see, Configuring other FIXEdge properties | ConfiguringotherFIXEdgeproperties PostponedFIXEdgeinitialization(Hot/Warmactiva...

Use Case 1: High Availability (HA) with Shared Configuration and Session Logs

Scenario:
Two standalone FIXEdge instances (Active and Passive) are deployed in a high-availability (HA) setup. Both instances share the same configuration files and session log directory. Each instance maintains its own application logs locally. The activation mode is set to either TryLock or TryHeartbeat. At any given time, only one instance (Active) manages FIX sessions, while the other (Passive) remains on standby.

Key Points:

  • Both FIXEdge instances reference the same lock file, specified by the ControlCentre.Activation.LockName parameter.

  • On startup, the first instance to acquire the lock transitions to Active (Hot mode), initializing all core services and managing FIX sessions. The second instance remains Passive (Warm mode), with core services uninitialized.

  • Session logs are stored in a shared directory, ensuring seamless session recovery and failover. Application logs are stored separately for each instance.

  • If the Active instance stops or fails, the Passive instance automatically acquires the lock and transitions to Hot mode, ensuring uninterrupted service.

Diagram 1: High Availability with Shared Configuration and Session Logs
Caption:
The diagram below illustrates two FIXEdge instances (Active/Hot and Passive/Warm) referencing shared session logs, configuration files, and a lock file. Only the instance holding the lock is active and manages FIX sessions.

Use Case 2: High Availability (HA) in case Centralized Configuration Management via FIXICC H2

Scenario:
FIXEdge instances are managed using FIXICC H2, with each instance assigned a unique name and configuration in the FIXICC H2 database. The activation mode is set to either TryLock or TryHeartbeat.  Both instances share a session log directory. Configuration synchronization is managed via Git.

Key Points:

  • Each FIXEdge instance maintains its own configuration in the FIXICC H2 database, its own application logs, and its own application configuration files (FIXEdge.properties and engine.properties).

  • Both instances reference the same lock file via the ControlCentre.Activation.LockName parameter in the FIXEdge.properties file.

  • Shared configuration files (such as Transport Adaptors configuration) are referenced by both FIXEdge instances. For configuring shared files, the IncludeProperties/ IncludeOptionalProperties parameters can be used, allowing auxiliary properties files to be included within the main FIXEdge.properties file.

  • Session logs are stored in a shared directory to ensure seamless failover. Application logs remain separate for each instance.

  • Configuration consistency between instances in the FIXICC H2 database is managed via Git, using the Import/Export Server Configuration functionality.

  • On startup, the first instance to acquire the lock transitions to Active (Hot mode), while the second remains Passive (Warm mode).

Diagram 2: Centralized Configuration Management with FIXICC H2

Caption:

The diagram below illustrates FIXEdge and FIXICC H2 instances (Active/Hot and Passive/Warm), each maintaining its own configuration in the FIXICC H2 database, as well as its own application logs and application configuration files (such as FIXEdge.properties and engine.properties). Configuration synchronization between instances is achieved via Git, using the Import/Export Server Configuration functionality. Both instances reference shared session logs, a lock file and shared configuration files (such as adaptor configurations).

Restart Procedure (Applicable to Both Use Cases)

There are two recommended procedures for restarting/updating FIXEdge instances in a high-availability setup. The choice depends on the specific operational requirements and the need to minimize downtime.

Standard Restart Procedure

  • Step 1: Always stop the Passive (Warm) instance first, then the Active (Hot) instance.

  • Step 2: After updates, start the Active instance first, then the Passive.

Rolling Update Procedure (Alternative)

This approach can minimize downtime by updating the Warm instance first and allowing it to take over as Active:

  1. Update the configuration on the Warm (Passive) instance.

  2. Restart the Warm instance.

  3. Shut down the Active instance.

    • The Warm instance will acquire the lock and become Active, now running with the updated configuration.

  4. Update the configuration of the former Active instance.

  5. Start the former Active instance.

    • It will not acquire the lock and will start as the new Warm (Passive) instance.

⚠️ Important Notes for FIXEdge Configuration in Passive (Warm) Mode :

  • If configuration changes are made while FIXEdge is running in Passive (Warm) mode, these changes will not be reloaded or applied when the instance transitions to Active (Hot) mode. To apply any configuration updates made during Passive mode, the FIXEdge instance must be restarted—just as it is when running in Active mode.

  • Configuration validation does not take place while the instance is in Passive (Warm) mode. All connection configuration and session parameter checks are performed only when the instance switches to Active (Hot) mode, as the initialization of the Core Services is postponed until that moment.