The Road to Akka.NET v1.0
petabridge.com
petabridge.com
Coming from Erlang, and familiar with a few basic actor concepts (but not with Scala's Akka terminology), I see a lot of new things and it seems a bit daunting.
I started browsing documentation and looked at:
http://getakka.net/wiki/Addressing
And see new things like:
ActorRef,
^ActorOf,
^ActorSelection,
DeadLetterActorRef,
EmptyLocalActorRef,
ActorCell,
ActorPath (physical and logical).
A URI spec that for "akka://"
The short answer is that these things enable various nice features of the framework, like automatically scaling out your actors, safely managing actor restarts, and managing message delivery for you.
Just to cover a few of those briefly:
What is an ActorRef?
An ActorRef is a reference or handle to an actor. The purpose of an ActorRef is to support sending messages to an actor through the ActorSystem. You never talk directly to an actor—you send messages to its ActorRef and the ActorSystem takes care of delivering those messages for you.
What are Props?
Think of Props as a recipe for making an actor. Technically, Props is a configuration class that encapsulates all the information needed to make an instance of a given type of actor.
One of the reasons Props encapsulate the entire recipe for making an actor (including deployment info) is so the system can manage restarts/lifecycle safely. It also can be serialized so that you can remotely deploy actors to other machines in a cluster -- BUT, this is invisible to you (location transparency, AKA you don't care if your actors are all in one process or on 10 machines spread around the planet).
What is an ActorPath?
Actor path == actor position in hierarchy.
Actors form intrinsic supervision hierarchies. This means there are "top level" actors, which essentially report directly to the ActorSystem itself, and there are "child" actors, which report to other actors.
Every actor in this hierarchy has an address. To send a message from one actor to another, you just have to know it's address (AKA its "ActorPath"). This is what a full actor address looks like: akka.tcp://MyActorSystem@localhost:9001/user/a1/b2.
What is ActorSelection?
This is using the actor path to get an ActorRef (handle to an actor). So instead of getting a handle to an actor by creating it, you're "looking up" the handle by its address. Kind of like looking up someone on Skype by their username.
####
You may find this post interesting to go in depth on actor hierarchies / paths / supervision: http://petabridge.com/blog/how-actors-recover-from-failure-h...
Also, if you're interested in learning Akka.NET, we're launching a free, self-paced bootcamp this Saturday. Details are here: http://learnakka.net
Hope this helps.
Technically, ActorSelection does not point to a specific ActorRef, it points to every ActorRef that matches the expression given. Wildcards are supported in this expression. So it's an expression that selects 0+ actors
ActorSelection will also match two different ActorRefs with the same name if the first one dies and is replaced by another (not restarted, in which case it would be the same ActorRef).
It looks like ActorRef is equivalent to Erlang's process ID's (PIDs). As there a message is sent to an actor's PID.
Props sound very powerful. I like the idea. With Erlang one can do it but with extra work. With live code-reloading and access to the module loader.
Do Actor hierarchies imply a global registration mechanism. If it does, wondering what kind of consistency/availability trade-offs it makes. Erlang's clusters do not handle network partitions too well sometimes and there are few custom registration/leader-election libraries for it. (locks, gproc, pg2)
No, all registration is done locally underneath the parent actor - i.e. if one parent creates three children, the only place where that state is registered is the parent itself. The root actor on each node can quickly figure out by traversing the tree whether or not a child at a given path exists or not.
The only exception to this convention are remote-deployed actors - if ActorSystem A deploys an actor remotely onto ActorSystem B, the RemoteDaemon (a system-level actor) keeps a record of who has actors deployed onto each other. That way if ActorSystem B dies (crash, network goes down, etc...) ActorSystem A can notify all of the local actors who depended on remote-deployed actors that those actors are effectively dead.
And this is a single datapoint, I know, but it's _ridiculously_ stable in my experience.
Literally, I've been telling people to just use Retlang since 2007. So many people still just fire up the threads and locks...
It is certainly far easier to write new implementations with Akka.NET in mind. But there are a couple of strategies that I found useful in retrofit scenarios:
1) Use adapter / proxy patterns (with DI / IoC). A bit tedious, but easy to back away from.
2) Use async more. It does force you to adopt a certain mental model, which helps make the transition to Akka a bit easier (rather than returning Task<T>.Result everywhere from Akka actors).
The project is based on Akka for JVM which has 5 years or so and is rock solid and very widely deployed, so you can rest assured the concepts are proven. The documentation still needs some work, but there are plenty of documentation for Akka for java/scala and most things have the same name so it's quite easy to find resources about it.