[akka-user] Best way to communicate with an Actor?

Hi Chanan,

I'd say the recommendation is to minimize shared knowledge (actor xy lives
at path a/b/c) exchange ActorRefs inside messages.



--
Cheers,
√

--
---
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+unsubscribe@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.

If you start with the assumption that you have the ActorRefs for the X,Y,Z
in someactor, I don't think you have a problem. Just "tell" the 3 actors
directly.

--
---
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+unsubscribe@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.

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.johannessen2@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.
--
---
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+unsubscribe@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

--
---
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+unsubscribe@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.

Ketil & Bjorn,

If you look at the second post in this thread from Viktor, it seems his
recommendation is the opposite.

--
---
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+unsubscribe@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.

Hi Chanan,

Yes, it states that you shouldn't distribute shared knowledge about your actor hierarchy throughout your program code. That is orthogonal to if you use an ActorRef or an ActorSelection to communicate. I think that it depends on your usage patterns and sometimes, especially during bootstrapping of a system you might need and ActorSelection to start of the communication to some named service provided by another actor.

I completely agree that if you intend to have a direct conversation with an actor, then you can exchange ActorRefs. Sorry if that was unclear in my previous reply.

B/

On 14 May 2014 at 18:50:44, Chanan Braunstein (chanan.braunstein@pearson.com) wrote:

Ketil & Bjorn,

If you look at the second post in this thread from Viktor, it seems his recommendation is the opposite.
--
---
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+unsubscribe@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

--
---
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+unsubscribe@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.

There are usecases where I believe is is not optimal to keep ActorRefs in
messages. Such a usecase would be an active record pattern usecase where
each actor instance represent a business entity. If you then have hundreds
or thousands of these actor instances, it is not feasible to keep actorrefs
of all the actors representing the business entities. Instead I believe it
would be better to enforce actor pathnames on these business entities based
on their "primary keys" and use actorSelection to resolve the enitities you
want to send messages to. This would be equivalent to looking up a business
entity from a sql database using the primary key.

--
---
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+unsubscribe@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.