I was assuming one should never rely on any specific ActorRef being "permanent" since that'd be assuming something about the implementation of it or its supervisor that could be wrong or could change later, and my application would break if it ever did go stale. Is that too paranoid, so for certain ActorRefs like this shard region it's safe to assume that it won't ever go stale?
To get the ActorSelection at startup time I'd get the ActorRef from ClusterSharding.shardRegion(...) then get its ActorPath and its ActorSelection from that. What's the overhead of sending to an ActorSelection vs. ActorRef? Using an implicit conversion from entry name to ActorRef is an interesting alternative too, thanks. Chris On Fri, Jul 18, 2014 at 8:02 AM, Martynas Mickevičius < [email protected]> wrote: > Hi Chris, > > if the ShardRegion will get restarted by its guardian, ActorRefs pointing > to it will not go stale. They will go stale if ShardRegion would be stopped > and then started again. But I can not see a likely scenario for that to > happen. > > I am not really sure about alternative 1). How would you construct actor > selection? > > Alternative 2) is very cheap, because ClusterSharding.shardRegion(...) is > a lookup in a map. You could abstract that away in a implicit conversion. > > > On Fri, Jul 18, 2014 at 6:52 AM, Chris Toomey <[email protected]> wrote: > >> We're going to use cluster sharding to route messages to the appropriate >> actors on the servers in a cluster. We'll have many actors that will be >> sending messages via the ShardRegion actor, and were thinking originally >> we'd inject that actor as a dependency into the actors that need it as we >> do other dependencies (e.g., an event bus). >> >> But since ClusterSharding.shardRegion() returns an ActorRef, presumably >> that could become stale (if the ShardRegion actor was restarted) and hence >> wouldn't make sense as an injected dependency. The alternatives I can >> think of are 1) obtaining the ShardRegion's ActorSelection and passing that >> as the dependency, or 2) passing in the shard entry name and calling >> ClusterSharding.shardRegion() every time to get the current ActorRef. Of >> these, 1) is definitely cleaner as it doesn't couple the dependent actors >> to ClusterSharding at all. >> >> Am I right in assuming that the performance overhead of 1) and 2) are >> comparable, and negligible in the grand scheme of things, compared to >> sending directly to the ActorRef? >> >> thx, >> Chris >> >> -- >> >>>>>>>>>> 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. >> > > > > -- > Martynas Mickevičius > Typesafe <http://typesafe.com/> – Reactive > <http://www.reactivemanifesto.org/> Apps on the JVM > > -- > >>>>>>>>>> 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 a topic in the > Google Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/ZRc6ftPEeW8/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- >>>>>>>>>> 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.
