Scala Days Copenhagen - 8 Akka anti-patterns you'd better be aware of

Scala Days 2017 Copenhagen - manuel.bernhardt.io - @elmanu

WHY THIS TALK?
Tools, of course, can be the subtlest of traps
— Neil Gaiman

MANUEL.BERNHARDT.IO
> Helping teams to get started with
reactive systems...
> ...and to keep them running
> Lightbend training partner (Akka,
Advanced Akka, Scala)

If you want to make enemies, try
to change something.
— Woodrow Wilson

ANTI-PATTERN #1
GLOBAL MUTABLE STATE

> it's okay for an actor to have mutable state
> as long as it retains total control over it and is the
only one to see it

HOW CAN IT HAPPEN?
> reference to mutable state in messages
> closing over mutable state in asynchronous calls
> passing shared mutable state to an actor's
constructor

WHY IS THIS BAD?

WHAT TO DO INSTEAD
> use immutable messages for state updates (e.g.
broadcasting for configuration changes)
> use queries for state inquiries (e.g. using the ask
pattern)
> for asynchronous calls, always use the pipe pattern

The two enemies of human
happiness are pain and boredom.
— Arthur Schopenhauer

ANTI-PATTERN #2
FLAT ACTOR HIERARCHIES

HOW CAN IT HAPPEN?
"Ceci n'est pas une hierarchie" - Magritte, 1928

IF YOUR ACTOR SYSTEM HAS NO HIERARCHY
YOU ARE MISSING THE POINT.

WHY IS THIS BAD?
> actor systems are designed to handle failures through
hierarchy
> ergo: no hierarchy, no failure handling
> why then bother to use actors in the first place?

How exception catch blocks are used in Java projects 1
1
Analysis of Exception Handling Patterns in Java Projects: An Empirical Study (S. Nakshatri, M. Hegde, S. Thandra)

WHAT TO DO INSTEAD?

WHAT TO DO INSTEAD?
Build hierarchies.

The mother of excess is not joy
but joylessness.
— Friedrich Nietzsche

ANTI-PATTERN #3
TOO MANY ACTOR SYSTEMS

HOW CAN IT HAPPEN?
> eagerly wanting to isolate things
> and not understanding how Akka
works
> (but the intent is good)

WHY IS THIS BAD?
> each actor system has at least one dispatcher backed
by a thread pool
> multiple actor systems = multiple thread pools,
contending for the same resources

WHAT TO DO INTEAD?

WHAT TO DO INSTEAD?
Bulkheading with custom dispatchers

contexts {
graph-db {
thread-pool-executor {
fixed-pool-size = 2
}
}
}
val graph: ActorRef = context.actorOf(
props = Props[Graph].withDispatcher("contexts.graph-db"),
name = "graph"
)

"Words, words, words."
— William Shakespeare, Hamlet

ANTI-PATTERN #4
LOGGING (THE WRONG WAY)

HOW CAN THIS HAPPEN?
> string concatentation
log().debug("Received message: " + msg.toString());
> non-asynchronous logging
> not turning debug logging off in
production settings
> let's get real: logging to files (it is
2017)

WHY IS THIS BAD?
> actor sytems are meant to process millions of
messages per second
> getting logging wrong has a huge performance impact

WHAT TO DO INSTEAD?
> use Akka's built-in logging facility
> carefully configure the logback appenders, use
asynchronous variants
> use string interpolation: log().debug("Received
message {}", msg);
> use a logging aggregation mechanism (logstash &
friends)

All that we see or seem is but a
dream within a dream.
— Edgar Allan Poe

ANTI-PATTERN #5BEING OUT OF TOUCH WITH THE HARDWARE

XKCDE 2
2
http://xkcd.com/1764/

WHY IS THIS A BAD THING?

WHY IS THIS A BAD THING?
fork-join-executor {
# Min number of threads to cap factor-based parallelism number to
parallelism-min = 2
# Parallelism (threads) ... ceil(available processors * factor)
parallelism-factor = 2.0
# Max number of threads to cap factor-based parallelism number to
parallelism-max = 10
}
ceil(available processors * factor)

WHY IS THIS BAD?
> suboptimal or simply wrong configuration for the
amount of CPU cores
> costs of context switching
> contending for network

WHAT TO DO INSTEAD?
> know your hardware and configure accordingly
> beware of virtualization (is the hypervisor lying to
you?)
> run load tests on the same hardware as your target
production system

"...some men aren't looking for
anything logical, like money. They
can't be bought, bullied, reasoned,
or negotiated with. Some men just
want to watch the world burn."
— Alfred Pennyworth, Batman, The Dark Knight

ANTI-PATTERN #6
BLOCKINGScala Days 2017 Copenhagen - manuel.bernhardt.io - @elmanu

> calling a synchronous API
> or calling an API that calls an API that calls an API...
that calls a synchronous API
> explicitly waiting for the completion of a Future
> using Thread.sleep (don't!)

WHAT TO DO INSTEAD?
> if you really must (legacy API), use a dedicated
dispatcher optimized for the blocking case (and limited
in resources)
> always use Future in combination with the pipe pattern
> use the akka scheduler if you are waiting for something

ASK AND PIPE
def receive = {
case ComputePi(precision) =>
val originalSender = sender()
implicit val timeout = Timeout(5.seconds)
val computation: Future[Pi] = piActor ? Compute(precision, originalSender)
val result = computation.recover { case t: AskTimeoutException =>
ComputationTimeout(originalSender, precision)
}
result pipeTo self
case Pi(value, originalSender) =>
originalSender ! PiResult(value)
case ComputationTimeout(originalSender, precision) =>
originalSender ! ComputationFailed(s"Sorry, $precision was too high.")
}

A man who dares to waste one
hour of time has not discovered
the value of life.
— Charles Darwin

ANTI-PATTERN #7
RE-INVENTING AKKA TOOLS

> not reading the documentation
> not keeping up with updates

> re-inventing at-least-once delivery (Akka Persistance
+ AtLeastOnceDelivery)
> re-inventing back-off supervision
(BackoffSupervisor)
> re-inventing message prioritization
(*ControlAwareMailbox, *PriorityMailbox,
*StablePriorityMailbox)

WHY IS THIS BAD?
> see the introductory quote for this anti-pattern

WHAT TO DO INSTEAD?
> read the documentation
> call me

This is the way the world ends
Not with a bang but a covfefe.
— T.S. Eliot

ANTI-PATTERN #8
USING JAVA SERIALIZATION

> leaving the default on
> Java serialization over the wire
> Java serialization in Akka Persistance

WHY IS IT BAD?
> performance penalty!
> poor candidate for protocol evolution - message
evolutions result in older components not able to
process them any longer
> persistance - messages and snapshots can't be
processed any longer after changes

WHAT TO DO INSTEAD?
> use a proper binary format
> protobuf, avro, thrift

THANK YOU
> Questions, comments, feedback?
> Contact me at manuel@bernhardt.io / @elmanu
> Check out more anti-patterns at https://
manuel.bernhardt.io

Scala Days Copenhagen - 8 Akka anti-patterns you'd better be aware of

More Related Content

Similar to Scala Days Copenhagen - 8 Akka anti-patterns you'd better be aware of

More from Manuel Bernhardt

Recently uploaded

Scala Days Copenhagen - 8 Akka anti-patterns you'd better be aware of