chapter five

5 Discovery and routing

 

This chapter covers

  • How to discover other actors
  • How to create routing actors

We talk in the previous chapter about fault tolerance not being complete without clustering. Here’s a question: How can an actor discover the existence of another actor if the latter didn’t get spawned by the former? One of the basic things we have to learn is how an actor finds another actor, how can they be discovered.

In Akka Typed, this has been solved in the same spirit of message passing, and the main protagonist in this whole picture is the Receptionist. The idea is quite simple; the Receptionist registers and subscribes actors to a specific key. With this model, when a registration occurs, all subscribers to that key get notified. Complementary to this, each new subscription to that key would get all previous registrations.

5.1 Receptionist

The Receptionist is an Extension, not an actor, and this means that there’s a normal class with only one instance in the whole Actor System. The Receptionist is a door to an Actor System and its actors, to all those actors registered to a specific key. We, as users, have to define each ServiceKey while the Receptionist can be found in system. Typically, context.system.receptionist

Listing 5.1 shows a sample of a ServiceKey named GoldenKey, to which actors can subscribe and register. First let’s define the requirements.

5.2 The built-in integration router pattern

5.3 Balance load using Akka routers

5.3.1 Akka pool router

5.3.2 Akka group router

5.3.3 Consistent Hashing Strategy

5.4 Implementing the router pattern using actors

5.4.1 Content-based routing

5.4.2 State-based routing

5.5 Summary