These are chat archives for petabridge/akka-bootcamp

26th
Aug 2016
Peter Parker
@qujck
Aug 26 2016 13:20
I'm confused by the statement your actors don't get tightly coupled to each other. How is akka://MyActorSystem/user/validationActor any less coupled to another part of the system than an IActorRef? All I can see is that we have lost compile time reference checks. Is there a blog post that goes into some advanced detail on this you can point me to?
Aaron Stannard
@Aaronontheweb
Aug 26 2016 17:55
@qujck ActorSelections have to be explicitly addressed
actor references do not - they have the property of location transparency
we talk about it some here https://petabridge.com/blog/akkadotnet-what-is-an-actor/ but I don't think that really does the concept justice
Aaron Stannard
@Aaronontheweb
Aug 26 2016 18:01
when you start using Akka.Remote (not covered in bootcamp) the benefits become more obvious
or when you start using the Akka.NET TestKit for unit testing actors
IActorRef instances can be easily swapped out to some test implementation
or even a remote actor
it all looks the same to the underlying actor
the IActorRef can belong to an actor anywhere in the hierarchy
an actor path can only belong to exactly one actor in exactly one spot in the heirarchy
so if it comes time to refactor, or the test, or to start working with the network
every unnecessary use of ActorSelection becomes a piece of technical debt
truth be told, I only really use ActorSelection in a couple of cases: to initiate an Akka.Remote connection to a remote system if I'm not using Akka.Cluster and whenever I intend to use a Group router, which uses ActorSelections under the hood to deliver messages to pre-existing actors
a third possible case might be using a wild-card ActorSelection: akka://MyActorSystem/user/*/foo - selects all grandchildren named foo regardless of the parent's name
huh, I see what you're saying now
yeah that piece of advice in bootcamp is bad
Aaron Stannard
@Aaronontheweb
Aug 26 2016 18:06
welp, I know what to do
Peter Parker
@qujck
Aug 26 2016 21:14
@Aaronontheweb thanks. The explanation along with the changes in #197 makes a lot more sense :-)
Aaron Stannard
@Aaronontheweb
Aug 26 2016 21:15
not sure how I missed that the first time
sorry for the confusion
Peter Parker
@qujck
Aug 26 2016 21:40

Ha, sorry @Aaronontheweb but I didn't get much further!
Unit-1/Lesson5 states

We assume you're talking about this IActorRef that is still getting passed into FileValidatorActor
In this case, we aren't using the handle for consoleWriterActor to talk directly to it. Instead we are putting that IActorRef inside a message that is getting sent somewhere else in the system for processing. When that message is received, the receiving actor will know everything it needs to in order to do its job.

but the code is clearly talking to directly to the consoleWriterActor
_consoleWriterActor.Tell(new Messages.InputSuccess(string.Format("Starting processing for {0}", msg)));
What am I missing here?

Aaron Stannard
@Aaronontheweb
Aug 26 2016 21:50
some clarification: I did not write Unit 1
ah, I know what that's trying to say
IActorRef is what we're using to communicate with that actor
rather than getting a reference to a ConsoleWriterActor object itself
you never get a reference to the underlying actor
Peter Parker
@qujck
Aug 26 2016 21:51
ah, ok thanks