Anti-Pattern on Manuel Bernhardt

Akka anti-patterns: too many actors

Mon, 06 Aug 2018 06:01:22 +0200

Update (07.08.2018): clarified optimal vs. suboptimal use cases of having many actors at runtime (it could have been misunderstood that Akka isn’t meant to build systems with many actors - it entirely is - but it is questionable whether that’s always the best approach)

It occurred to me that I haven’t written yet about this very frequent anti-pattern. It is to be found in codebases written by developers who have just discovered the actor model.

Akka anti-patterns: Java serialization

Fri, 20 Jul 2018 11:29:45 +0200

Akka makes use of serialization when messages leave the JVM boundaries. This can happen in mainly two scenarios: sending messages over the network when using Akka Cluster (do not use Akka Remote directly) or using Akka Persistence.

Now here’s the catch: the default serialization technology configured in Akka is nothing but the infamous Java serialization, which Mark Reinhold called a “horrible mistake” and which Oracle plans to dump in the near future anyway.

Akka anti-patterns: stateless actors

Wed, 30 May 2018 07:31:24 +0200

Actors are object-orientation done right (as opposed to say, objects in Java): their state is not visible from the outside and they communicate via messages. There’s no way to break encapsulation because you can’t peek into an actor’s state while it is running. That’s the entire point of actors: they provide you with the illusion of a safe space in which things are executed sequentially, one message after the other, allowing you to use mutable state inside of your actor without having to worry about race conditions (well, almost: don’t leak the state).

Akka anti-patterns: overusing ActorSelection

Tue, 20 Mar 2018 09:27:15 +0100

Akka’s ActorSelection makes it possible to look up actors by logical path in the hierarchy:

1

val selection: ActorSelection = context.actorSelection("../processor/storage")

This selection can then be used like ActorRef in order to send messages to it using the tell or ask patterns:

1
2
3


selection ! Storage.Store("important words")

val allWords: Future[Seq[String]] = selection ? Storage.RetrieveAll

ActorSelection is therefore quite useful and allows more flexibility when designing an actor system given that trees can be built dynamically and queried dynamically at runtime. That being said, there are a few things that you should be aware of when using this mechanism.

Akka anti-patterns: naming your application components after Akka concepts

Sat, 26 Aug 2017 06:00:47 +0200

So you’ve just learned Akka and are tremendously excited. It’s got dispatchers, routers, supervisors - so many shiny things to play with, and in style (I mean, come on, a dispatcher sounds a lot nicer than, say, an AbstractSingletonProxyFactoryBean).

And so it happens that, perhaps even unknowingly to you (you’re busy configuring a pool router), your actors start getting names such as:

Dispatcher
IncomingRouter
FailureSupervisor

I’ve observed this on three projects now, for two of which I delivered an introductory Akka training to the team beforehand. I’d say that this anti-pattern is especially to be found in projects where people are just getting started with Akka.

Akka anti-patterns: trusting the network

Tue, 20 Jun 2017 05:06:33 +0200

One anti-pattern I’ve observed in networked Akka applications is a tendency to forget that it is, well, networked and to treat the network as a friendly place.

Trusting the network to be reliable

How does that look like? Well, consider the following piece of code:

1

actorOnDifferentNode.tell(veryImportantMessage, sender());

Akka’s default message sending mechanism is the fire-and-forget tell method. And that works great - until it doesn’t. See, tell has at-most-once message delivery semantics. This means that in theory (and in practice!) messages may not make it to their destination.

Akka anti-patterns: using remoting

Thu, 08 Jun 2017 07:14:03 +0200

Senior developer using Akka remoting directly to build a special type of cluster

Whilst I have always successfully discouraged my clients from using Akka Remoting in their application, I often get questions regarding remoting while talking about anti-patterns at conferences and user groups.

Don’t get me wrong. I love Akka remoting. Especially the new Aeron-based Artery remoting version that is based on UDP rather than TCP. Whilst it maintains the same delivery guarantees, it is quite a bit faster than the TCP counterpart.

Akka anti-patterns: blocking

Mon, 15 May 2017 07:59:20 +0200

This is probably one of the most frequent (and dangerous) anti-patterns when it comes to working with Akka. Let’s look at an adequate description of the mindset you must be in in order to use it:

So maybe you didn’t actually want to see the world burn. Maybe you thought that this one time it was okay to call blocking code inside of an actor. Little did you know that, seven months later, this decision would bring down the entire system minutes after its official launch and announcement in the media.

Akka anti-patterns: being out of touch with the hardware

Mon, 21 Nov 2016 17:02:31 +0100

Choosing Akka as a tool is often - if not always - driven by the need for good performance. Surely, the actor model itself is appealing as a means for organizing and reasoning about code, but this isn’t in itself a good reason enough to use the Akka toolkit. If all you are concerned about is a nice way to organize code and build modular applications you might as well pick the Spring Framework which has a very rich and clear component model and provides very good support for building software where performance isn’t one of the driving factors.

Akka anti-patterns: logging (the wrong way)

Wed, 31 Aug 2016 05:59:33 +0200

Update: removed rogue toString call in the second code example, since it was unnecessary (and harmful).

Proper logging

Debugging actor systems is no small feat, even when there is IDE support for it. In fact, debugging any asynchronous system for that matter is a rather complicated task. Which is why, especially during development, it is not entirely uncommon to rely on DEBUG level logging to get a sense of how messages flow between actors. Whilst doing so is fine, there are a few precautions that need to be taken when logging at DEBUG level (or any other level). Remember, logging ranks very high on the list of top 10 performance mistakes.

Akka anti-patterns: too many actor systems

Tue, 23 Aug 2016 07:25:10 +0200

Admittedly I’ve seen this one in use only one time, but it was one time too many. For some reason I keep seeing clients come up with this during design discussions and reviews though, therefore it makes it into the list of Akka anti-patterns.

What I am talking about is this:

Many ActorSystems on a single JVM, competing for resources

Reasons I hear for this design:

isolation of concerns: each ActorSystem is separated, hence failure of one system does not affect the other
custom classloading in the ActorSystem, dynamically loading libraries and isolating them between systems
using multiple Akka versions without having to restart

And I am not talking about designs where there are 2 or 3 ActorSystems on the same JVM here, but possible hundreds if not thousands. Now, Akka itself does not share any global state so you can theoretically pull this off. But should you?

Akka anti-patterns: race conditions

Tue, 16 Aug 2016 05:00:39 +0200

The actor model makes it possible to build highly-concurrent applications through the notion that actors obey the actor send rule and the actor subsequent processing rule, hence creating a single-threaded environment inside of an actor.

That being said, it’s all an illusion: as we have briefly talked about previously, Akka’s dispatchers make sure that messages are being processed by actors and so the thread by which one message is processed may not be the same as the one by which the next message is going to be processed.

Akka anti-patterns: flat actor hierarchies or mixing business logic and failure handling

Tue, 09 Aug 2016 04:00:31 +0200

Flat actor hierarchy. Sad actors being all flat.

One of the fundamental ideas built into Akka is the one of failure handling through parental supervision.

In other words this means agencing actors in such a way that parent actors that depend upon the correct execution of a child to perform their work are also responsible for deciding what to do when one of the child actor crashes.

An exception thrown inside of an actor results in that actor crashing, prompting its parent to decide what to do, which it does using a SupervisorStrategy. You should not be writing defensive try...catch blocks inside of an actor - except perhaps for a few rare cases, this too is an anti-pattern! Instead the idea is to let it crash and handle failures through another channel entirely.

Akka anti-patterns: shared mutable state

Tue, 02 Aug 2016 15:00:40 +0200

When I work with clients on designing actor systems there are a few anti-patterns that seem to make it into initial, non-reviewed designs no matter what. In this series of short articles I would like to cover a few of those.

Even though the Akka documentation points this out in various places, one of the favourite anti-patterns I’ve seen is use is sharing mutable state accross actor boundaries.