Hi Anatoliy, 19 mar 2014 kl. 12:49 skrev Anatoliy Kaverin <[email protected]>:
> I see, > thanks for replies!!! > It looks I didn't really get how wildcard actor selection look up works, but > now I got a clear picture. > > I have loosely coupled Actors, some of them are dynamic and later addressed > by already existing ones. So, sending ActorRef is not an option. Nope, there is always a way: in this case the dynamic actors introduce themselves to the existing ones, preferably because they received the needed ActorRefs in their constructor. > Original problem I've faced is related to UT. Unreal Tournament? ;-) (beware of the TLAs) > Let's imagine, that I have next 2 Actors in production: > /user/WatchActor/DoCoolStuffActor/DynamicGuidActor > > and another one: > > /user/WatchActor/DoAnotherStuffActor > > When I cover DoAnotherStuffActor with UT - one of the cases is to mock > DynamicGuidActor, as by workflow I need to find it via Identify message. > > The problem as in UT I have one level less: > /user/DoAnotherStuffActor > and > /user/DoCoolStuffActor/DynamicGuidActor > > DoAnotherStuffActor is testd in isolation (no Spring context) and all > dependencies wired manually with stubs and mocks. > For that I need -> TestActorRef for DoAnotherStuffActor. So, I cannot create > same hierarchy as in production. > > Thankfully after you comments it became clear that wildcard cannot help me - > I wanted a universal actor selection path to cover both production and UT > scenario. > Sibling search resolved my needs so far (search via > ../DoCoolStuffActor/DynamicGuidActor path ) A better way is to not use lookups at all, precisely because they make the hierarchy inflexible and unit testing hard. Now you might ask: why does Akka support them at all? The reason is remote interaction, where the first contact between two systems needs to be established somehow. If you want to test such an actor, you would need to inject the lookup path and use a local one during the test (e.g. `testActor.path`) Regards, Roland > > On Wednesday, March 19, 2014 11:15:01 AM UTC+2, rkuhn wrote: > Hi Anatoliy, > > in general it is much easier to reason about the system if you explicitly > introduce the actors to each other instead of relying on String-based lookups > (which tie down your hierarchy as you now learnt). You can do that by passing > an ActorRef to the constructor of a new actor or within a message sent to > that actor. > > Regards, > > Roland > > 19 mar 2014 kl. 07:37 skrev Anatoliy Kaverin <[email protected]>: > >> I see, >> but why ForwardingActor is not matched? >> >> Another question -> imagine that I have some different paths and I only care >> about finding a leaf, like this: >> /user/someActor/someotheActor/someImportantActor >> >> I have someImportantActor known and don't care about it's parents -> is it >> possible to lookup and skip parent levels? >> Or wildcard only used for partial search in names? >> >> On Tuesday, March 18, 2014 4:48:24 PM UTC+2, Patrik Nordwall wrote: >> The wildcard in "/user/*/ChildActor" will match 2 actors, both >> ChildCreationActor and LookingActor. The second path will not match and you >> get ActorIdentity with ref null. The first path will match your expected >> ChildActor. You will receive two ActorIdentity but you happen to use only >> the first. The order of these messages are undefined. >> >> Regards, >> Patrik >> >> >> On Tue, Mar 18, 2014 at 2:18 PM, Anatoliy Kaverin <[email protected]> wrote: >> Greetings, >> I've been using Akka in my Java based backend and faced some issue related >> to ActorSelection API if it is used from ActorContext (from inside Actor). >> For some reason I cannot find existing Actors via Identify message for >> specific paths. >> >> Imagine, that I have such Actor hierarchy: >> USER -> Parent Actor -> Child Actor >> USER -> WorkerActor >> >> And let's assume that I would like to locate Child Actor via actor selection >> and use wildcard for the purpose. >> So, I'm building such path: >> /user/*/ChildActor >> >> For some reason -> if this path is used for lookup via global Akka system >> context -> ActorIdentity provides me ActorRef >> But, if I will perform the same lookup but from inside WorkerActor via >> ActorContext -> Identify ActorRef is null. >> >> For me it seems like a bug and inconsistent behavior. >> I've provided code with different scenarios and the correct one. >> >> JUnit code with the issue >> >> Another one point - for some reason if I call actorSelection.tell from >> inside Worker Actor -> messages got delivered to the target ChildActor. But, >> I see some errors in dead letters office: >> 15:08:21.916 INFO [default-akka.actor.default-dispatcher-3] >> a.a.EmptyLocalActorRef - Message [java.lang.String] from >> TestActor[akka://default/user/$$a] to >> Actor[akka://default/user/$$a/ForwardingActor] was not delivered. [1] dead >> letters encountered. This logging can be turned off or adjusted with >> configuration settings 'akka.log-dead-letters' and >> 'akka.log-dead-letters-during-shutdown'. >> >> Any ideas? >> >> -- >> >>>>>>>>>> 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. >> >> >> >> -- >> >> Patrik Nordwall >> Typesafe - Reactive apps on the JVM >> Twitter: @patriknw >> >> >> >> -- >> >>>>>>>>>> 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.
