Hi, You are right that using ActorSelection is a be a better idea if you are not directly responsible for the life and death of an actor and that you haven't been given any guarantees. It's still perfectly valid to have schemes where an actor registers its ActorRef with another actor (e.g, workers registering with a master) but then you would need to use DeathWatch on the master to remove unavailable workers.
Do you have any ideas about how we might improve the documentation? B/ On 13 May 2014 at 15:47:15, Ketil Johannessen (ketil.johanness...@gmail.com) wrote: I find the Akka documentation a bit confusing with respect to this, as the API documentation for ActorRef indicates that it is actually intended for message passing, but elsewere in the doc (http://doc.akka.io/docs/akka/snapshot/general/addressing.html), it states: "You can create an actor, terminate it, and then create a new actor with the same actor path. The newly created actor is a new incarnation of the actor. It is not the same actor. An actor reference to the old incarnation is not valid for the new incarnation. Messages sent to the old actor reference will not be delivered to the new incarnation even though they have the same path." -which means that holding an actorref in your code and assuming it is valid is a wrong assumption. If you hold an actorref in your code you should monitor it by DeathWatch, which leads to complex statehandling in your actor related to the watched actor's lifecycle. Your actors monitoring the lifecycle of other actors may or may not be the same ones responsible for recreating them in case of termination. So how should your actors be notified of the reincarnation of an actor with a new actorref?. I believe using actorSelection is a better idea, isolating the responsibility of death watch to the actor actually being responsible for the reincarnation. On Tuesday, April 22, 2014 3:07:15 PM UTC+2, Chanan Braunstein wrote: There could be a few ways you can get the ActorRefs X,Y,Z to "someactor" you could, for example, create a message from SomeActor to the parent of X,Y,Z (in this example it would /users) and ask it to return the ActorRefs. Then you would save them in someactor and use them to talk to X,Y,Z. I ended up going a different route, and decided not to save the ActoRefs in "someactor". Since in my case /users is a singleton I send it messages to route to the children. It uses its getChild and children functions to route to one or more actors under it as needed. -- >>>>>>>>>> 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. -- Björn Antonsson Typesafe – Reactive Apps on the JVM twitter: @bantonsson JOIN US. REGISTER TODAY! Scala Days June 16th-18th, Berlin -- >>>>>>>>>> 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.
