3 Things Learned from using Akka in a Coding Workshop

Here are 3 learnings from last weeks Akka coding session, in which all participants connected their Actors in order to participate in a Prisoner’s Dilemma competition.

1. Prepare Your Networking Infrastructure for Akka

Akka needs TCP connections in order to work. In some venues you will run into issues with Router Firewalls that block certain ports, and other surprises. We were lucky that our host didn’t block any ports, but we had a backup Wireless Router just in case.

When using Akka with its default settings, some machines will use their local loopback address (e.g.”127.0.0.1″) for their akka host. In this case, their Actors will not be able to receive any messages. The solution is to get their LAN ip address manually (e.g. via ifconfig) and put it into the application.conf:

akka.remote.netty.tcp.hostname = "192.168.0.81"

2. Expect Latency

Hosting system timing out and receiving late responses out of context (see debug messages on the left side)

Dealing with 25 machines worked remarkably well. During the workshop, each participant had at least one Actor connected to our “hosting Actor”. The average time the hosting Actor waited for a response from a participants Actor was about 100 milliseconds (keep in mind we used a wireless network).

However, as soon as the number of messages on the network climbed to about 100 messages per second, the hosting Actor started to ignore some of the other actors because it waited over 1 second for a response. The hosting Actor used Akka’s ask pattern to wait for the players responses in context:

// get player responses
implicit val timeout = Timeout(1 second)
(player.ref ? PrisonerRequest(otherPlayer.name)).foreach {
     case response : PrisonerResponse => self ! PlayerResponse(player, otherPlayer, response)
}

As the messages took too long to arrive, some responses were collected by the host at a time when the ask pattern already ran into the 1 second timeout. Suddenly, the hosting actor started receiving those messages out of context, because the virtual actor created by the ask pattern was already gone.

3. Let It Crash

Part of the fun of a workshop like this is that people will start to mess with the system (yes, I’m looking at you, Wolfgang! 😉 )

That’s actually a good thing, because a lot of things can be learned. In our case, there was an “exploit” that allowed people to connect as many actors as they wanted to the central host, and so at one point our high score was flooded with players. The system kept running, but the tournament started to slow down because of the high number of players.

We did, however, run our hosting system in Untrusted Mode. So at least, this makes it difficult for everyone to start and stop Actors on the system remotely 😉