Akka cluster integration in allows us to provide distributed services to the Platform. Akka-based services run in their own cluster on SC processes, and can be run separately or together depending on your requirements.

Example of Akka cluster structure

A cluster is made up of a set of member nodes. A service is distributed over a cluster with each node hosting some part of the application. The cluster membership information is passed between nodes using a gossip protocol. When a node can prove that the membership information that it has locally been observed by all the other nodes in the cluster, gossip convergence is reached. After gossip convergence, a leader for the cluster can be determined. Any node can become the leader, and become responsible for managing cluster membership. Gossip convergence cannot occur while any nodes are unreachable, which also means that the leader cannot perform cluster management during this period. Even if gossip convergence has not been reached, it does not affect the service running on the cluster, which can continue to serve requests as normal.

Process flow of Akka cluster member nodes

When shutting down an SC with a running akka cluster, the member is gracefully removed from the cluster, and the cluster continues to function as long as there are nodes left in the cluster. When an SC has an ungraceful shutdown, or a if a network partition occurs, the member becomes unreachable. In this case, the member must become available again or the member must be marked as DOWN. You can down a node using the mzsh akka command. See /wiki/spaces/MD82/pages/3778967 in the Command Line Tool user's guide and Managing Akka Cluster Failure.

Akka Configuration

It is possible to configure the Akka cluster and the Akka cluster clients. For further information, see Listing of the Reference Configuration in https://doc.akka.io/docs/akka/2.4.12/general/configuration.html#config-akka-remote. However if you require to do this, contact  Support.