Let it crash

Using a singleton should not be the first design choice, but for some use cases it is convenient and sometimes also mandatory to ensure that you have exactly one actor of a certain type running somewhere in the cluster.

Therefore, this specific use case is made easily accessible by the Cluster Singleton Pattern in the contrib module. It manages singleton actor instance among all cluster nodes or a group of nodes tagged with a specific role. The singleton actor is always running on the oldest member. The cluster failure detector will notice when oldest node becomes unreachable due to things like JVM crash, hard shut down, or network failure. Then a new oldest node will take over and a new singleton actor is created.

Read more in the documentation.

The cluster knows the order members were added to the cluster. akka.cluster.Member has a method isOlderThan to compare two members by their age. This is useful when you need a stable order of the nodes.

For example, this is how you can keep track of the members, sort them by age, and send each message to the first 3 nodes: 

Not all nodes of a cluster need to perform the same function: there might be one sub-set which runs the web front-end, one which runs the data access layer and one for the number-crunching. Deployment of actors—for example by cluster-aware routers—can take node roles into account to achieve this distribution of responsibilities.

The roles of a node is defined in the configuration property named akka.cluster.roles and it is typically defined in the start script as a system property.

The most important change is that an actor system can only join a cluster once. Additional attempts will be ignored. When it has successfully joined it must be restarted to be able to join another cluster or to join the same cluster again. It can use the same host name and port after the restart, but it must have been removed from the cluster before the join request is accepted. Unsuccessful join attempts are automatically retried.

These strict rules means that you can safely restart a process without any confusion between the state of the old and new member with same host name and port.

Startup of seed nodes has also been improved. Seed nodes and other nodes can be started in any order. The node configured as the first element in the seed-nodes configuration list must be started when initially starting a cluster, but thereafter it can be stopped and started again just like any other node. All nodes can have the same configuration and start script.

Your feedback pushed us to an improved solution for how nodes can join the cluster. Thanks for reporting!

Using a singleton should not be the first design choice, but for some use cases it is convenient and sometimes also mandatory to ensure that you have exactly one actor of a certain type running somewhere in the cluster.

This can be implemented by subscribing to LeaderChanged events, but there are several corner cases to consider. Therefore, this specific use case is made easily accessible by the Cluster Singleton Pattern in the contrib module.

The singleton actor is always running on the leader member, which is nothing more than the address currently sorted first in the member ring. This can change when adding or removing members. With the names given above the path of singleton actor can be constructed by subscribing to LeaderChanged cluster event and the actor reference is then looked up using actorFor:

Read more in the documentation.

With a configuration option you can define required number of members before the leader changes status of ‘Joining’ members to ‘Up’.

You can defer startup of actors until the cluster has at least the defined number of members.

Read more in the docs for Scala or in the docs for Java.

The member nodes of the cluster collects system health metrics, such as heap memory and CPU usage. The metrics is spread to other nodes and consumed by a new type of router that performs load balancing of messages to cluster nodes based on the cluster metrics data.

The router is defined in the same way as other routers:

and in this case it’s configured as follows:

Many thanks to Helena Edelson for her great contributions to the metrics design and implementation. In an upcoming blog post she will describe this topic in more detail.

Read more in the docs for Scala or in the docs for docs for Java.

Dear hAkkers,

We—the Akka committers—are pleased to be able to announce the availability of Akka 2.0.5. This version contains a number of small bug fixes, for the full list of tickets closed see below, the most notable ones are

• allow null as reply from a TypedActor
• properly set stateData when stopping FSM actor
• rethrow impl in 2.0.4 yields ClassCastException for non RuntimeExceptions

Read More

Thanks to excellent work by Raymond Roestenburg and Piotr Gabryanczyk the Akka module for Apache Camel is completely rewritten in Akka 2.1.

Camel is an open-source framework based on known Enterprise Integration Patterns and it is great for integrating Akka systems with other external systems. The Akka Camel module provides an easy to use bridge between actors and Camel endpoints.

Read More

A new router uses consistent hashing to select a connection based on the sent message.

ConsistentHashingRouter maps messages with same hash to the same routee, as far as possible. It means that when a routee is added, it takes its share of elements from the other routees and when it is removed, its elements are shared between the remaining routees. This can be very useful together with the new cluster aware routers.

Read more in the docs for Scala or in the docs for Java.