Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Cluster functionality suggests that several instances of the FIXEdge Java server work together where one instance is primary and the other ones serve as standby nodes.

The cluster service provides high availability (HA) of the FIXEdge connectivity service.

The Cluster Manager service automatically resolves and registers FEJ servers as cluster nodes and monitors their state. It defines the primary node automatically at the cluster initial start.

If the primary node fails for some reason, the remaining nodes in the cluster can automatically choose the next leader node in the cluster, or it can be done manually depending on the working mode of the cluster.

The cluster service allows establishing communication of several applications, which are placed on different boxes. Each application of that kind, which uses the cluster service, is a cluster node. The node can be run in the leader or backup mode. The leader mode means that the node is active, accepts the network connection and performs some useful work. Backup nodes are used for preparing fast replacing if the leader node becomes unavailable. In such a case, the backup node could be switched to the leader mode and it could provide the same service.

The Replication service maintains backup copies of primary's Persistence API - New Design Draft storages and supports actual and ready-to-work copy of current data on standby servers within the cluster. Replication supports both synchronous and asynchronous modes for certain FIX sessions.

  • Synchronous replication is recommended when data loss is critical (for example, for order processing).
  • Asynchronous replication is recommended when performance is very important while the clear data is not essential or data can be restored for other sources (for example, for market data processing).

The Replication service uses the Aeron transport for transmitting data to backup instances. In the synchronous mode, the storage sends notifications about every operation to backups and waits for acknowledgment back. It blocks calling thread till receiving acknowledgment or till the predefined timeout expires.

The replication service consists of 2 parts: leader and backup. Depending on the instance role, it needs to initialize and start one or another instance.

Leader instance is responsible for:

    • notifications about exist and new storages

    • delivering notifications about storage’s operations

    • handling synchronization requests

Backup instance is responsible for:

    • creating required storages on backup

    • synchronize storages

    • update storages state (process notifications about storage’s operations)

  • No labels