Roland, I go with your proposed solution in my usecase since it's the best way to increase performance in my case.
But do you have any documentation pointing out the "best practice" when it comes to using publish vs tell, actorrefs vs actorSelection? I have tried to search for such a paper, but so far haven't found any. Ketil On Wednesday, May 14, 2014 10:06:49 AM UTC+2, rkuhn wrote: > > 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]<javascript:> > >: > > 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 <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]) >> 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 <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]. >> 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 <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] <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.
