Receptionist semantics: Register, Subscribe. Possible unsafe code in Documentation?

Akka Actors
,
1

In the Actor discovery section of the documentation there is an example where Actor A spawns Actor B, and in Actor B’s setup they register with the Receptionist. However immediately after spawning Actor B, Actor A subscribes to the service key Actor B uses to register with the Receptionist. If Actor A’s subscribe message gets to the Receptionist after the Register message of Actor B wouldn’t Actor A not receive the Listing response from the Receptionist as there would be no change in the listing from the moment Actor A subscribes, thus making the example code not entirely correct?

Wouldn’t it be safer for Actor A to subscribe to the key. Spawn Actor B (without any registration in setup), and then have Actor A register Actor B themselves thus guaranteeing the ordering in which the messages arrive at the Receptionist.

2

When subscribing to the Receptionist there will always be an initial Listing with the set of services at the time of registration, potentially followed by subsequent registrations or deregistrations will lead to a new Listing message.

This means that if you, roughly at the same time, have one service registering and one subscriber, the subscriber can either see two Listing messages:

  1. first an empty listing, then a listing with the service in it
  2. a listing with the service in it

It is much better to handle updated listings correctly than to try to enforce some ordering. Consider the tight coupling needed if scaling up the number of services and subscribers, out across several clustered nodes and then trying to ensure order of registrations and subscribers.

The sample is somewhat superficial to be kept simple, but will work for both scenarios, the Guardian either starts no pingers upon the first, empty, listing and then gets another listing that causes it to start pinger children or gets a listing with the service and starts a pinger for it.

Where the sample falls apart is if you over time add or remove services, which would be more realistic. For that to work the Guardian behavior would need some more clever logic to sync what pingers are running with what services are in every updated listing it gets.

3

Ah thank you. It was not clear to me that Subscribe led to an initial listing. Although now that makes sense.

4

I created a PR with a small change to make that more clear: https://github.com/akka/akka/pull/29046/files

1 Like