too many IActorRefs in Akka.net

Question

lets say i have the following Actor hierarchy :

user
|____A___|---E
|        |---F
|        |---G
|
|____B___I
|____C___J
|____D___K

Lets say Actor E Needs to have IActorRef's of Actors I,J,K, passing the Actor Ref's in the constructor gets messy if the the system scales and needs more Actors , and user ActorSelection not advised to use locally.

is there A proper and dynamic way of getting ActorRef's as the system scales?

i have thought a lot about whether i should ask this question or not as it can interpreted as opinion based question , but im really strugling with this problem as i have searched a lot and it is not yet clear what is the best practice to this problem as the code can get really messy and unreadable in time.

Answer 1

Just start sending messages, instead of trying to pre-configure Actors with (many) other Actors. It makes initialisation complicated indeed, when there are many different Actors. Also: you cannot regard IActorRef handles passed to a constructor as static and eternally valid: when an Actor goes offline, you need a mechanism to detect that and null its handle, or delete it. The other Actors in the cluster need to watch Akka log messages.. which are not guaranteed.. etc..

Instead: when you connect a new Actor to the cluster, emit (push) your Identity through a pubsub. Your new Actor message could be: ActorSytem.Name+IActorRef+RoleString.

https://getakka.net/articles/clustering/distributed-publish-subscribe.html

The RoleString is a descriptor for the task of your Actor. Other actors can decide to register your IActorRef, based upon RoleString.

In the process, other subscribers (Actors) to the pubsub will pick up your identity and store your identity. Then, they emit their identity in the same way, through the same pubsub. As a result, you'll receive the RoleString identities you need in responses.. and the other cluster nodes (Actors) know you exist.

When the Actor needs to disconnect, emit a pubsub message first, before actually disconnecting the Actor from the Cluster. Doing so, other actors know the Actor went off line.

One pitfall with this strategy: preventing endless pubsub loops (I/O avalange). Solution I use: prevent an Actor from sending too many messages by testing the time since its previous pubsub message. Put e.g. 1 message per minute, regardless of other Actors.. this will result in a heartbeat, rather than an avalange of messages. And you'll be informed in regular intervals of the online status of all Actors. An exit/offline message is not needed in this case.