Akka anti-patterns: too many actors

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 …

Akka anti-patterns: Java serialization

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 …

Akka anti-patterns: stateless actors

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 …

Akka anti-patterns: overusing ActorSelection

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

This selection can then be used like ActorRef in order to send messages to it using …

Akka anti-patterns: trusting the network

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. How does that look like? …

Akka anti-patterns: using remoting

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 …

Akka anti-patterns: blocking

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 …

Akka anti-patterns: logging (the wrong way)

Update: removed rogue toString call in the second code example, since it was unnecessary (and harmful). Debugging actor systems is no small feat, even when there is IDE support for it. In …