On Fri, Feb 6, 2015 at 4:20 PM, <[email protected]> wrote: > Hi – > > We have been using Akka for some time now as part of our online service ( > www.sickly.org) and overall have been very happy with it. Having started > with creating and running actors locally, on a single server instance, a > few months back we started scaling up by moving some actors out onto a > separate instance. This has all worked pretty well. > > We're now looking at scaling up still further and at this point, finding > the documentation unclear as to how location transparency is really meant > to work. > > Let's say you start with Actors A, B and C, all running on Instance 1. > You create them using actorOf and send messages between them using the > ActorRefs that are returned, as per the Akka documentation. Fine. > > Now let's say you want to deploy your codebase across Instance 1 and > Instance 2. You configure things so Actors A and B are running on Instance > 1, and Actor C is running on Instance 2. Actor B is a shared service (in > our case a persistent message queue that we have implemented in Akka) which > is accessed from Actor A and Actor C. When Actor A sends a message to > Actor B, it can do so using an ActorRef as before, because it's > communicating locally. But when Actor C sends a message to Actor B, it's > doing so remotely so needs to look up an ActorSelection. But Actor A and > Actor C are communicating with Actor B using the same shared code, and as > ActorRef and ActorSelection don't share a useful common base class, the > upshot is you no longer have the location transparency promised by Akka. >
That is intentional because sending with actor selection and sending with actor ref have different semantics. The actor ref points at a specific incarnation of an actor and is not valid when that incarnation has stopped, while the actor selection will deliver to whatever actor happens to be located at the given path. > > We could at this point: > > 1. Switch to using ActorSelection everywhere, but it seems there's > going to be a performance penalty (considering many uses of it will be > local) which could be significant and surely could be avoided, or > > That is not a good option, as you realized. > > 1. Implement our own mechanism for resolving ActorSelections to > ActorRefs, caching ActorRefs to cut down on lookups, and handling any > lifecycle errors appropriately (e.g. if Instance 2 is restarted, the > ActorRef will need to be refreshed). But this seems like hard work and the > sort of thing that would surely be part of Akka if it was really necessary; > and besides, we'd end up with Future[ActorRef] instead of ActorRef, meaning > we'd have to re-code every usage we have of those ActorRefs - which again > seems to fly in the face of location transparency, or > > Actor selection must be used to bootstrap things between remote nodes, unless you use cluster specific tools such as cluster aware routers, DistributedPubSub, ClusterSharding. An actor that doesn't have an actor ref to a destination can send the Identify message with actor selection to retrieve the actor ref and then it can watch the ref. See Identifying Actors via Actor Selection <http://doc.akka.io/docs/akka/2.3.9/scala/actors.html#Identifying_Actors_via_Actor_Selection> > 1. Implement some kind of wrapper for Either[ActorRef, ActorSelection] > that we can send messages to using "!" and that passes them to the > underlying ActorRef or ActorSelection - but this really does seem like the > sort of thing we shouldn't have to be doing, or > > That is not a good option, as you realized. > > 1. ... ? > > How are we meant to handle this? > > Many thanks, > Jeremy > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
