Understanding the resolution and destruction of remote ActorRef

Akka Actors
1

I have a setup where I have a huge number of actors running which are spread across machines and a HTTP service which will talk to these Actors.

The HTTP service resolves a RemoteActorRef on every request, sends a message to it and completes the request. After doing that the RemoteActorRef is left orphan.

Following questions are in concern machine which is running the HTTP service -

  1. Is there any link created between local actorSystem with the resolved RemoteActorRef?
  2. Does RemoteActorRef just represents the string ActorPath or it also has some extra mechanism to route messages to the actor (like a local proxy)?
  3. Are the RemoteActorRefs garbage collected?
  4. Should I be worried about any kind of resource leak?

So far my understanding after reading the Akka code is:

  • The only link between local ActorSystem and RemoteActorRef is that there is a field localAddressToUse in RemoteActorRef which holds the path of the local actor system (and there is no parent child relationship or proxy between them).
  • ActorRefs are garbage collected.

Let me know if my understanding is correct or if I am missing anything.

2

The RemoteActorRef has a reference to RemoteTransport which is the subsystem of the ActorSystem responsible for interacting with remote ActorSystems. There is also a LRU cache for remote actorrefs so that frequently used remote actorrefs will be the same object rather than a new one for each resolution.

The cache can keep up to 1024 RemoteActorRefs around even though there is no reference in any code that is live. Except for that they are GC:d just like any other object.

If the ActorRef you resolve once per request is to the same remote actor, and that actor stays alive throughout the life of the application, it could make sense to avoid doing that resolution work each time and instead doing it up front and keeping the ActorRef around/shared between the requests.

3

Thank you for clarifying.

To clarify our use case, there will be huge number of actors running out of which any one it needs to be resolved per request. So in this case your suggestion might not work.

4

For a huge number of actors somewhere distributed across the cluster you may want to look into if Cluster Sharding could be a good fit for you. It does not resolve individual actors but instead groups them into shards and addresses them through an identity.

5

We already have Akka cluster setup in place which is solving our domain problem. Your first response clears out our doubts (about the GC of actor refs and actor ref resolution). I think we don’t need Cluster Sharding to solve our problem.

Thank you for your help and alternative suggestions.