Lab1: GroupService

This lab is a warmup exercise. It asks you to build a simple service (GroupService) to manage multicast group communication among a set of Akka actors. The assignment exercises your understanding of Akka actors and messaging and also illustrates some issues in building applications on key-value stores.

The group abstraction is as follows.

There is a collection of numbered groups: each group is named by an integer (a groupID or groupkey).
An actor may join any group; the actor becomes a member of the group.
An actor may leave any group of which it is a member.
An actor may send (multicast) a message to any group: the message is sent to all members of the group.

The GroupService is implemented as an application of a simple key-value store, which is provided in the rings package (KVStore). Rings comes with a simple key/value application (RingService) that reads and writes RingCell values at random keys, with some checking. Your assignment is to replace that application with your GroupService implementation. Also modify KVAppService to instantiate your group service instead of the RingService. Do not change the KVStore or KVClient.

Group membership lists are stored in the KVStore. Since the keys for the store are BigInt (128 bits), your group IDs should be BigInt. Define a new data structure to store in the KVStore to represent the membership list. KVClient provides caching over the KVStore, but it may be simpler and safer to use the "direct" read and write operations, as RingService does.

Like RingService, GroupService consists of a set of actors (GroupServers) that start together and provide the service collectively. The LoadMaster calls KVAppService to instantiate the actors, then sends bursts of empty command messages. Upon receiving a command, a server chooses an action and executes it. The test terminates after a configured number of commands are sent and acknowledged. Do not change LoadMaster or TestHarness.

You can reuse much of the RingService code to handle and acknowledge received commands, and choose actions according to a weighted random distribution.

To keep things simple, the actors that join and leave groups and send messages to groups will be the GroupServers themselves. The actions for the GroupServers include: joining a random group, leaving a random group (of which the GroupServer is a member), or sending a multicast message to a random group (of which the GroupServer is a member). Choose parameters and weights to ensure a suitable level of "interesting" activity. Examples include: bias toward joining more groups as the test executes, and/or weight or constrain the choice of groups, to ensure that some groups have multiple members. You might also take actions for incoming group messages, e.g., act as an intermediary that randomly forwards the incoming message to another group. (Take care not to create unbounded loops!)

Your system should be scalable. That is, for a given number of groups and a given number of GroupServers, the work of managing group membership should be balanced "evenly" among the GroupServers and among the KV storage servers. However, be sure to take care to think about concurrency races. What happens if two actors try to join the same group at the same time? Under no circumstances should join/leave operations be "lost", nor should a group membership list become corrupted.

Use your application to experiment with the Akka messaging system. Here are some questions to consider and answer:

Do actors ever receive messages originating from a given actor out of order? What if the messages are forwarded through an intermediary?
What if two actors multicast to the same group? Does each member receive the messages in the same order?
Do actors ever receive messages for groups "late", after having left the group?
How does your choice of weights and parameters affect the amount of message traffic?
How can you be sure your code is working, i.e., the right actors are receiving the right messages?

Part of the assignment is to write a few paragraphs about what you discovered from your experiments. In particular, make up an "interesting" test scenario and describe the resulting behavior in a short paragraph.

Using Scala/Akka

The resources page has some sources on Scala and Akka. The Scala documentation is quite good, and you will find many common questions answered on stackoverflow. Scala is reasonably mature, but be alert for unexpected behaviors. Using Akka at this time presents two challenges to keep in mind:

Akka has evolved rapidly over the last few years. Its relationship to Scala has changed. That means that there is lots of outdated material on the web. If you are looking at documentation for Akka or Scala, be sure it matches the version of the software you are using. For anything else, be mindful of the date, and keep your guard up.
The Akka docs are vague on specifics. In general, they are written for people who are already experts. They do discuss some basic concepts, but the treatment is not authoritative.

We will stick to doing relatively simple things with Scala and Akka. It is also possible to do complicated things that are also interesting, but we will stay away from them because there are enough interesting things to do that are simple. The sample code has examples of (almost) every part of Akka/Scala that you really need to use.