Hi Ketil, actorSelection is implemented by sending a message that traverses the actor tree, one by one. This is the reason for the duplication of the messages and the lack of consistency: the traversed tree itself is distributed and concurrently modifies itself. There is an optimization which does the traversal without going through all the intermediate mailboxes, but that is not something that you should rely on for your non-functional requirements.
My recommendation is still that the sender of your “bursts” should acquire the ActorRef of the destination and send messages directly, since that is the heavily optimized way of communication that we focus on. This does not mean that any actor besides that sender needs to use DeathWatch; and not even the sender would need to in case that it care about whether the messages are processed or not (since that requires an explicit reply anyway—which will also be very useful in avoid OOME due to sending a too big burst without observing back pressure). Regards, Roland 14 maj 2014 kl. 09:46 skrev Ketil Johannessen <[email protected]>: > 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]>: > >> 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. 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. >> >> B/ >> >> On 13 May 2014 at 17:02:30, Ketil Johannessen ([email protected]) 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]. >>> 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. >> -- >> 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 [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. > > > > Dr. Roland Kuhn > Akka Tech Lead > Typesafe – Reactive apps on the JVM. > twitter: @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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @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.
