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. 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 2. 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 3. 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 4. ... ? 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
