CodeMash 2013 Day 4 Session 3


# Effective Actors
Jamie Allen @jamie_allen

Actors are concurrent lightweight processes that communicate through asynchronous message passing
NO state sharing

Note – this is focused on Akka which is a Scala actor framework

A set of Actors live in an ActorSystem

Supervisor Hierarchies – specifies handling mechanisms for groupings of actors in parent/child relationship
Actors can be remote to each other – in a different JVM or even a different machine.
Worker Supervision – supervisors hold critical data and pass it to workers ala Map/Reduce.
You can scale by creating multiple instances of an actor – no order can be assumed – they might run in any order
Define routing to determine how to spread work across actors – there are various routing algorithms
Actors share threads – they are not tied to threads.

1 – Actors should only do one thing (same as SRP)
Use Actors with abandon – an actor only has 300 bytes of overhead
2 – Block only when you have to
Blocking leads to actor starvation, resource waste, and horrible performance
Database access will be blocking – use specialized actors that only retrieve data – once it gets the data it should throw that to another actor
You get better async performance if you push data than if you pull it. (This is essentially event-driven programming)
3 – Do not optimize prematurely
Don’t parallelize until you have proof you need it (profile, runtime logs, etc. – Some Measurement)
Be prepared for race conditions – things will happen in an indeterminant order. You have to expect that things will not be the way you wanted them to be.
Provide all of the necessary information required to process a message in the message
4 – Be explicit in your intent
Name your actors – provides a means to find them and better logging
Never publish this or a real reference to an actor – only deal with actors via actor references and send messages to them
Avoid closures over the “sender” in an actor – it will probably be completely different at the time that the code is executed.
Use immutable messages – it enforces which actor owns the data