At which point should actors' behaviors be split - akka

Question

I'm completely new to Akka. I am having a hard time grasping when I should split what used to be class methods/behavior into akka messages. Many examples show the messages received as one line - println("Howdy").
Let's assume I want to do the following:
Given a predefined set of regular expressions
Given an input stream of sentences from a book. Each message is a sentence.
Perform regular expression on the sentence
Increment count of matches and non-matches for the regular expression
If match, Perform HTTP post the sentence.
What is the guideline that akka experts use in their head to break this up? Would I make each step here a separate message rather than several method calls? In my head, The only thing I would use an akka message for, would be #1 (each message), and #6 (blocking http call). That would make my handling of each sentence actually perform a decent amount of work (but non-blocking work). Would it be similar to when I decide to use async over not using async? Which to me, is only ever when I have the chance for a blocking operation.

Answer 1

I assume that a state you want to track in your actor is the number of matches per regular expression.
In this case, your initial approach is valid in case you don't have a lot of regular expressions. If you have a lot of them, and every sentence goes through every expression, you will perform a lot of work on the actor thread. This work is non-blocking in the sense that there is no I/O, but it is actually prevents the progress of other messages sent to this actor, so it is blocking in this sense. Actors are single-threaded, so if you have a lot of incoming sentences actor's mailbox will start to grow. If you use an unbounded mailbox (which is default) you'll eventually go OOM.
One solution would be to dispatch regex matching to a Future. However, you can't share actor state (which is match count per regex) with that future, because (in general case) it will cause race conditions. To work around this, the result of your future will send another message to your actor with counts that need to be updated.
case class ProcessSentence(s: String)
case class ProcessParseResult(hits: mutable.Map[Regex,Int], s: String)
case class Publish(s: String)
class ParseActor {
val regexHits = Map("\\s+".r -> 0, "foo*".r -> 0)
def receive = {
case ProcessSentence(s) => Future(parseSentence(s, regexHits.keys)).pipeTo(self)
case ProcessParseResult(update, s) =>
// update regexHits map
if(update.values.sum > 0)
self ! Publish(s)
case Publish(s) => Future(/* send http request */)
}
def parseSentence(s: String, regexes: Seq[Regex]): Future[ProcessParseResult] =
Future{ /* match logic */}
}

Answer 2

The way I recommend approaching designing with Akka is to first identify the state in your problem.
Let's start there:
If you have state, evaluate if an actor is a simpler approach than synchronization and locking
If you don't have state, evaluate if you actually need to use an actor
If you have state, then an actor may be a good fit as it can help ensure you safely handle concurrent access to the state in the actor, and its fault tolerance mechanisms will help your application recover if that state becomes corrupt causing application errors.
In your case, a simple counter or two can be handled with Java's atomic integers, so I would actually recommend that you use a basic class instead of an actor. It will be much simpler than using an actor. If you want to return a future, you can use Java8s CompletableFuture or Scala's concurrent.Future and the result will be simpler than using an actor.
With all of that said, if you DO want to use an actor, the design might not warrant multiple actors because you only have one piece of state.
As a general rule, your actors should have only one responsibility - much like good object oriented design. While you might accept a message in your one single actor, you may decide to split the logic into multiple classes still. So you might have your 'RegexActor' and then you might have 'MatchBehavior' implemented with strategy pattern that the RegexActor is passed on construction.
All in, I don't think you need to build a bunch of actors - actors give you asynchronous boundaries between things but you will still benefit from using good OO in the behaviours that the actor has. The actor has one message - that of handling lines of the book - but it has a few behaviours that can be composed in several different classes. I would use basic classes for that behaviour and have the actor delegate to those other classes after it receives the message.
You want things to be simple - there is a cost of loss of type safety and added code when using actors so I recommend you make sure there is a good reason for using it - either state that exists in a concurrent environment or distribution.