FAQ
I asked a somewhat similar question before but this time its more focused.

I have a hierarchy like so:

/project/users/user-<userid>

There is just one "project", one "users", and many user-<userid> actors.

If I want to send a message from a different actor out side of
this hierarchy to one or more users, for example from /project/someactor,
it seems to me I have 3 basic ways of doing it (forgetting about EventBus,
which is a fourth):

1. I always have an ActorRef for /project. I can send it a message which it
will forward to /project/users who will grab the correct actor from its
children collection and forward the message to it.

2. I can construct an ActorSelection from /project/someactor and send
message to the ActorSelection directly.

3. I can store in /project/someactor in a HashMap or some other data
structure all the /project/users/user-<userid> ActorRef's, grab them from
the map when I need to send one a message and directly send a message to
the ActorRef

So, my questions are: what is the preferred way to communicate with an
actor in this case? Realizing that there might not be a preferred way -
what is a bad idea to do if any? What are the pros and cons that people see
in each way? Lastly, does anyone have a way I missed?

Thanks,
Chanan

--
---
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.

Search Discussions

  • √iktor Ҡlang at Apr 16, 2014 at 7:15 pm
    Hi Chanan,

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

    On Wed, Apr 16, 2014 at 7:51 PM, Chanan Braunstein wrote:

    I asked a somewhat similar question before but this time its more focused.

    I have a hierarchy like so:

    /project/users/user-<userid>

    There is just one "project", one "users", and many user-<userid> actors.

    If I want to send a message from a different actor out side of
    this hierarchy to one or more users, for example from /project/someactor,
    it seems to me I have 3 basic ways of doing it (forgetting about EventBus,
    which is a fourth):

    1. I always have an ActorRef for /project. I can send it a message which
    it will forward to /project/users who will grab the correct actor from its
    children collection and forward the message to it.

    2. I can construct an ActorSelection from /project/someactor and send
    message to the ActorSelection directly.

    3. I can store in /project/someactor in a HashMap or some other data
    structure all the /project/users/user-<userid> ActorRef's, grab them from
    the map when I need to send one a message and directly send a message to
    the ActorRef

    So, my questions are: what is the preferred way to communicate with an
    actor in this case? Realizing that there might not be a preferred way -
    what is a bad idea to do if any? What are the pros and cons that people see
    in each way? Lastly, does anyone have a way I missed?

    Thanks,
    Chanan

    --
    Read the docs: http://akka.io/docs/
    Check the FAQ:
    http://doc.akka.io/docs/akka/current/additional/faq.html
    ---
    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.


    --
    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.
  • Chanan Braunstein at Apr 21, 2014 at 12:38 pm
    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.
  • Björn Antonsson at May 14, 2014 at 6:45 am
    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.
  • Chanan Braunstein at May 14, 2014 at 4:50 pm
    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 at May 15, 2014 at 6:29 am
    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.
  • Ketil Johannessen at May 15, 2014 at 8:04 am
    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.

    On Thursday, May 15, 2014 8:29:04 AM UTC+2, Björn Antonsson wrote:

    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.b...@pearson.com<javascript:>)
    wrote:

    Ketil & Bjorn,

    If you look at the second post in this thread from Viktor, it seems his
    recommendation is the opposite.
    --
    Read the docs: http://akka.io/docs/
    Check the FAQ:
    http://doc.akka.io/docs/akka/current/additional/faq.html
    ---
    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+...@googlegroups.com <javascript:>.
    To post to this group, send email to akka...@googlegroups.com<javascript:>
    .
    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 <http://typesafe.com/> – Reactive <http://reactivemanifesto.org/> Apps
    on the JVM
    twitter: @bantonsson <http://twitter.com/#!/bantonsson>

    JOIN US. REGISTER TODAY! <http://www.scaladays.org/>
    Scala <http://www.scaladays.org/>
    Days <http://www.scaladays.org/>
    June 16th-18th, <http://www.scaladays.org/>
    Berlin <http://www.scaladays.org/>
    --
    ---
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupakka-user @
categoriesscala
postedApr 16, '14 at 5:51p
activeMay 15, '14 at 8:04a
posts7
users4
websiteakka.io
irc#akka

People

Translate

site design / logo © 2022 Grokbase