In my usecase I don't hold a direct reference to the actorrefs, as they happen to be child actors under their respective parent actors. Of course you could argue that I should have sent message to the parent actors and let them propagate the messages to the relevant child actors, to respect my intended capsulation of the child actors. But in this particular case I face a performance issue since I need to "burst" a lot of messages to the child actors at some point of time during the execution, and I believe the parent actor may become a bottleneck since it processes all other messages to the child actor.
I believe there are some usecases where a publish would be to expensive performance wise, and actorref not a good pattern (since it requires DeathWatch throughout your application), that's why I believed an actorSelection with wildcards was a viable solution. On Wednesday, May 14, 2014 9:26:27 AM UTC+2, rkuhn wrote: > > This exchange gave me the idea that it might be best to introduce a marker > trait that says “don’t log as DeadLetter”. We could inherit that for all > internal IO messages, for example, or for remoting messages and streams. > And users can use this to mark messages that might regularly be dropped, as > in this example. > > OTOH I find it a bit “sloppy” to use ActorSelection with wildcards when > you know exactly which actor you want to be talking to: in almost all cases > it is possible to solve the problem by passing around ActorRefs (as > constructor arguments or in messages). The only exception is talking to > different actor systems, where bootstrapping requires that one first > message to the other side without having an ActorRef for it. > > Regards, > > Roland > > 14 maj 2014 kl. 09:20 skrev Björn Antonsson > <[email protected]<javascript:> > >: > > I don't think that this is a bug, it was designed that way, but it might > be unwanted behavior. The ActorSelection will try to traverse the path that > you give it, and send messages to all matching sub paths. The > ActorSelection doesn't know that it's ok to not find something at the end > of the path in your case. > > There are a few different ways to tackle this going forward. One is better > DeadLetter logging <https://github.com/akka/akka/issues/15163>. Another > one is to change or add to the behavior of ActorSelection. > > If you have a good use case where you think that this is important, please > open > a ticket <https://github.com/akka/akka/issues>. > > B/ > > On 13 May 2014 at 17:02:30, Ketil Johannessen > ([email protected]<javascript:>) > wrote: > > I have two root actors with corresponding child actors at the following > paths: > /akka://mysystem/user/rootA/childA > and > /akka://mysystem/user/rootB/childB > > when I try : > > ActorSelection ref= system.actorSelection("/user/root*/childA"); > ref.tell(obj,self()); > > > I get DeadLetterWarning on messages going intended to "/ > akka://mysystem/user/rootB/childB" > whereas my intended recipient (/akka://mysystem/user/rootA/childA) > received the messages as intended. This litters my logging and possibly > also uses some unnecessary resources in my application. > > I would expect the actorSelection to only send messages to paths matching > the entire expression and not just the first part up to the wildcard? > > Have I misinterpreted the pattern matching, or is this a bug? > > -- > >>>>>>>>>> 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] <javascript:>. > To post to this group, send email to [email protected]<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/> > > > -- > >>>>>>>>>> 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] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > > > > > *Dr. Roland Kuhn* > *Akka Tech Lead* > Typesafe <http://typesafe.com/> – Reactive apps on the JVM. > twitter: @rolandkuhn > <http://twitter.com/#!/rolandkuhn> > > -- >>>>>>>>>> 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.
