Actor lifecycle management and routers – Akka Actors for .NET


Porting Akka to .NET

I finally got around to implement full lifecycle management in Pigeon.
The Pigeon actor behavior is now consistent with real Akka.

The following Scala test: https://github.com/akka/akka/blob/master/akka-actor-tests/src/test/scala/akka/actor/ActorLifeCycleSpec.scala
Is now ported to .NET and shows that the lifecycle events fire in the expected order: https://github.com/rogeralsing/Pigeon/blob/master/Pigeon.Tests/ActorLifeCycleSpec.cs

I’ve also managed to port the fundamentals of the Akka Routers, so RoundRobinGroup routing is now in place: https://github.com/rogeralsing/Pigeon/wiki/Routing

Completely boring blogpost but this is what I’ve been up to the last few days :-)

 

Configuring Pigeon – Akka Actors for .NET


When I began to write the configuration support for my Akka Actors port “Pigeon”, I used JSON for the config files.
I’ve now managed to get some nice progress porting Typesafe’s Configuration library too.
So Pigeon now uses HOCON notation for the config files, and thus, allows for re-use of real Akka config files in Pigeon.

This means you can write configurations like:

var config = ConfigurationFactory.ParseString(@"
# we use real Akka Hocon notation configs
akka {
    remote {
        #this is the host and port the ActorSystem will listen to for connections
        server {
            host : 127.0.0.1
            port : 8080
        }
    }
}
");
//consuming code
var port = config.GetInt("akka.remote.server.port");

This might sound overly optimistic, since Pigeon currently only utilize a handful of the properties from the config.
But still, it’s pretty much only substitution support and numeric units that is missing from the config lib now, so I hope to have a fully working config system in a few days.

Once that is done, I will start incorporating it in the ActorSystem and it’s sub modules.
For those who are interested, the configuration support can be reused in other kinds of applications.
You can read up on the HOCON spec from Typesafe here: https://github.com/typesafehub/config/blob/master/HOCON.md
My port to .NET can be found here: https://github.com/rogeralsing/Pigeon/tree/master/Pigeon/Configuration

If you are interested in using Actor Model programming for .NET, please check out Pigeon:
https://github.com/rogeralsing/Pigeon

Configuration and Remote support for Pigeon – Akka Actors for .NET


I’ve been working quite a bit on my Akka port this weekend.
Finally got a a configuration system in place.
Trying to stay close to how Akka works, I decided to go for a Json based configuration, this is fairly close to the real Akka configurations while still not beeing too alien to .NET developers.

A config could look something like this:

Pigeon : {
    Actor : {
        Serializers : {
            json : ""Pigeon.Serialization.JsonSerializer"",
            java : ""Pigeon.Serialization.JavaSerializer"",
            proto : ""Pigeon.Remote.Serialization.ProtobufSerializer""
        },
        DefaultDispatcher: {
            Throughput : 100
        }
    },
    Remote : {
        Server : {
            Host : ""127.0.0.1"",
            Port : 8080
        }
    }
}

Remoting is also treated as an extension to the ActorSystem, so there is no longer any awkward subclass, like this:

using (var system = ActorSystem.Create("MyClient",config,new RemoteExtension()))
{

So now it’s possible to actually use Pigeon on two different machines using the config for host/port.

Read more at: https://github.com/rogeralsing/Pigeon

Throughput of Pigeon – Akka Actors for .NET


As some of you might know, I’m making an unofficial port of Akka for .NET.
https://github.com/rogeralsing/Pigeon.
(Why not Akka# or dotAkka? I simply assume that TypeSafe that makes Akka don’t want to be associated with spare time projects like this, so I try not to stain their brandname)

One important factor of a successful actor framework is how fast you are able to process messages – less overhead on message processing means better scalability.
Akka made some noise when they managed to process 50 million messages per second in their ping-pong benchmark example on an 48 core server.

I’ve now ported this benchmark to Pigeon so that one can get a hint of how the two compares.
This is the results from an 8 core laptop:

 Worker threads: 1023
 OSVersion: Microsoft Windows NT 6.2.9200.0
 ProcessorCount: 8
 ClockSpeed: 3392 MHZ
 Actor count, Messages/sec
 2, 7073000 messages/s
 4, 11760000 messages/s
 6, 14534000 messages/s
 8, 18039000 messages/s
 10, 20161000 messages/s
 12, 18785000 messages/s
 14, 17523000 messages/s
 16, 17482000 messages/s
 18, 17931000 messages/s
 20, 18575000 messages/s
 22, 18975000 messages/s
 24, 20920000 messages/s

I’m pretty pleased with the performance so far.
The code for the benchmark actors looks like this:

private static object Msg = new object();
private static object Run = new object();

public class Destination : UntypedActor
{
    protected override void OnReceive(object message)
    {
        if (message == Msg)
            Sender.Tell(Msg);
    }
}

public class Client : UntypedActor
{
    public long received;
    public long sent;

    public long repeat;
    private ActorRef actor;
    private TaskCompletionSource<bool> latch;

    public Client(ActorRef actor,long repeat,TaskCompletionSource<bool> latch )
    {
        this.actor = actor;
        this.repeat = repeat;
        this.latch = latch;
    }
    protected override void OnReceive(object message)
    {
        if (message == Msg)
        {
            received++;
            if (sent < repeat)
            {
                actor.Tell(Msg);
                sent++;
            }
            else if (received >= repeat)
            {
                latch.SetResult(true); //instead of java countDownLatch
            }
        }
        if (message == Run)
        {
            for (int i = 0; i < Math.Min(1000,repeat); i++)
            {
                actor.Tell(Msg);
                sent++;
            }
        }
    }
}

If there are anyone out there that would like to join building a high performance Actor Model framework (staying as close to Akka as possible), let me know.

Hotswap and Supervision – Pigeon – Akka Actors for .NET


This is a follow up on my previous post; http://rogeralsing.com/2014/01/01/pigeon-akka-actors-for-net/

The code for this project can be found here: https://github.com/rogeralsing/Pigeon

And again, before I begin, please do note that Pigeon is just my hobby project of cloning some of the Akka Actor API.

Akka is in no way affiliated with me or my project.

I’ve done some refactoring to mimic Akka’s API more closely.
e.g. I’ve removed the need for IMessage on messages, you can now pass any object as an actor message.

I’ve also added some more nifty features from Akka – Hotswap and Supervision.

Hotswap is the ability to change the message receiver, this is useful if you have some sort of state machine, e.g. if you receive one message and you want to handle messages differently once that message is received.

Like this:

public class GreetingActor : UntypedActor
{
    protected override void OnReceive(IMessage message)
    {
        Pattern.Match(message)
            .With<Greet>(m => {
                Console.WriteLine("Hello {0}", m.Who);
                //this could also be a lambda
                Become(OtherReceive);
            });
    }

    void OtherReceive(IMessage message)
    {
        Pattern.Match(message)
            .With<Greet>(m => {
                Console.WriteLine("You already said hello!");
                //Unbecome() to revert to old behavior
            });
    }
}

In the example above, the actor will first output “Hello {who}” if a Greet message is passed to it.
But if we pass another greet message to it, it will output “You already said hello”.
This is ofcourse a contrived example, but it is very useful for larger state machines.
e.g. Lets say we write a game and each player/bot has its own actor.
We could then make it respond differently if you are stunned, dead, or trapped by some spell or whatever.

You can read more about this feature in the Akka documentation here: http://doc.akka.io/docs/akka/snapshot/java/untyped-actors.html#HotSwap

The next feature is Supervision, supervision lets a parent actor monitor it’s children and decide what to do if they start failing.
e.g. you can configure it to restart, restart or escalate if an exception of a given type occurs too many times in a given timespan.

Like this:

public class MyActor : UntypedActor
{
    private ActorRef logger = Context.ActorOf<LogActor>();

    // if any child, e.g. the logger above. throws an exception
    // apply the rules below
    // e.g. Restart the child if 10 exceptions occur in 30 seconds or less
    protected override SupervisorStrategy SupervisorStrategy()
    {
        return new OneForOneStrategy(
            maxNumberOfRetries: 10,
            duration: TimeSpan.FromSeconds(30),
            decider: x =>
            {
                if (x is ArithmeticException)
                    return Directive.Resume;
                if (x is NotSupportedException)
                    return Directive.Stop;

                return Directive.Restart;
            });
    }

    ...
}

The “logger” above is a child actor of “MyActor”, this means that MyActor is the parent and supervisor for logger.
If logger starts throwing exceptions, those will be forwarded to the supervisor strategy, and depending on configuration, the parent can resolve the issue by restarting or stopping the child etc.
You can read about this in the Akka documentation: http://doc.akka.io/docs/akka/snapshot/general/supervision.html

Pigeon – Akka Actors for .NET


I’m working on a port of the Java/Scala framework Akka, or rather the Actor Model part of it.
As of now, this is only a bit more than a weekend hack, so don’t expect too much.
But I already have a couple of nice features in:

Git hub repository goes here: https://github.com/rogeralsing/Pigeon

Write your first actor:

public class Greet : IMessage
{
    public string Who { get; set; }
}

public class GreetingActor : UntypedActor
{
    protected override void OnReceive(IMessage message)
    {
        message.Match()
            .With(m => Console.WriteLine("Hello {0}", m.Who));
    }
}

Usage:

var system = new ActorSystem();
var greeter = system.ActorOf("greeter");
greeter.Tell(new Greet { Who = "Roger" }, ActorRef.NoSender);

Remoting support:

//Server Program.CS
var system = ActorSystemSignalR.Create("myserver", "http://localhost:8080);
var greeter = system.ActorOf("greeter");
Console.ReadLine();

//Client Program.CS
var system = new ActorSystem();
var greeter = system.ActorSelection("http://localhost:8080/greeter");
//pass a message to the remote actor
greeter.Tell(new Greet { Who = "Roger" }, ActorRef.NoSender);

There are still alot of things that needs to be implemented/fixed.
Actor paths don’t work correctly at the momeent for example.
Supervision and other features are missing etc.

One nice feature I managed to squeeze in was “Futures”.
Futures in Akka is pretty much Task of T in .NET.
However, Futures in Akka is synchronous and you need to (bussy) wait for them to complete.
[edit]
As Alexey Romanov pointed out in the comments, this is not true.
You can get async futures using either onComplete callbacks,
or using Scala async support https://github.com/scala/async and use async/await.

In Pigeon however, we have Async/Await support.

You can async await responses from other actors like this:


//inside an actor
var result = await Ask(someActor, messageToAsk);
result.Match()
    .With(m => {
         Console.WriteLine("got awaited result {0}",m);
    })
    .Default(_ => Console.WriteLine("Unknown message"));

The nice thing is that the await continuation will execute in the actor context, so there is no threading issues inside the actor here.

Hope you like it :)

Using Command Pattern to capture language and intent for services


This is a follow up to my previous post http://rogeralsing.com/2013/12/01/why-mapping-dtos-to-entities-using-automapper-and-entityframework-is-horrible/

That post was about both the technical and conceptual problems faced when using DataTransferObjects(DTOs) as the base of your service design.

In this post I will try to show you another way to model services that does not suffer from those problems on neither plane.

First, let’s talk about language.
I want to capture language and intent when modelling services, that is, I want to see the same vocabulary that the domain experts on my team use in my code.

Let’s re-use the same scenario as we used in my previous post:

//entities
class Order
    int Id //auto inc id
    string DeliveryAddress
    ICollection Details

class Detail
    int Id //auto inc id
    decimal Quantity
    string ProductId

Maybe our domain experts have told us that we need to be able to do the following:

Place new orders.
Edit an existing order.
Add a product to an order.
Change the quantity of a product in an order.
Remove a product from an order.
Set a delivery address for an order.
Ship an order.
Cancel an order.

If you are used to think in terms of CRUD, you might look at this and think:
Well, “placing an order” is the same as “CreateOrder”.
And “Editing an existing order” is the same as “UpdateOrder”.
And “Cancel an order” is the same as “DeleteOrder”
And I’ll solve the rest just by passing my DTO, let’s put a DeliveryAddress and a nullable ShippingDate property on order and just copy details from the DTO to the order.

OK, you will probably get away with it (for now), but the code will look like something in the previous post liked at the top here.
And most importantly, you will lose semantics and intention.

e.g. Does “order.ShippingDate = DateTime.Now” mean that the order is shipped now? that it is up for shipping?
What if we reset the order.ShippingDate to null? does that mean that the order have been returned to us?
Is that even a valid state transition?
Your code might be small’ish, except for the weird change tracking replication you have in your update service.

Wouldn’t it be nice if we instead could capture valid state transitions and the domain experts language at the same time?
What if we do something like this:

public int PlaceNewOrder(){
    using (UoW.Begin())
    {
       var order = new Order();
       UoW.Add(order);
       UoW.Commit();
       return order.Id;
    }
}

public void AddProduct(int orderId,string productId,double quantity)
{
    using (UoW.Begin())
    {
       var order = UoW.Find(o => o.Id == orderId);
       if (order.IsCancelled)
          throw new Exception("Can not add products to cancelled orders");

       var detail = new Detail
       {
           ProductId = productId,
           Quantity = quantity,
       }
       order.Details.Add(detail);
       UoW.Commit();
    }
}

public void ShipOrder(int orderId,DateTime shippingDate)
{
  ...
}

This is of-course a very naive example, but still, we managed to capture the language of the domain experts, and even if this will make our code more verbose, it captures explicit state transitions in a very clean way.
Someone new to the project can open up this code and they will be able to figure out what is going on in each individual method.
e.g. you will most likely not misunderstand the intention of a method called “ShipOrder” which takes an argument called ShippingDate.

So far so good, but from a technical point of view, this code is horrible, we can’t expose a service interface that is this fine-grained over the wire.
This is where command pattern comes in.

Lets redesign our code to something along the lines of:

public static class OrderService
{
    public static void Process(IEnumerable<command></command> commands)
    {
        var ctx = new MyContext();
        Order order = null;
        foreach (var command in commands)
            order = command.Execute(ctx, order);
        ctx.SaveChanges();
    }
}

public abstract class Command
{
    public abstract Order Execute(MyContext container,Order order);
}

public class CreateNewOrder : Command
{
    public override Order Execute(MyContext container, Order order)
    {
        order = new Order();
        container.OrderSet.Add(order);
        return order;
    }
}

public class EditExistingOrder : Command
{
    public int OrderId { get; set; }
    public override Order Execute(MyContext container, Order order)
    {
        order = container.OrderSet.Single(o => o.Id == OrderId);
        return order;
    }
}

public class SetDeliveryAddress : Command
{
    public string DeliveryAddress { get; set; }

    public override Order Execute(MyContext container, Order order)
    {
        order.Address = DeliveryAddress;
        return order;
    }
}

public class RemoveProduct : Command
{
    public string ProductId { get; set; }

    public override Order Execute(MyContext container, Order order)
    {
        order.Details.Remove(d => d.Name == ProductId);
        return order;
    }
}

public class AddProduct : Command
{
    public string ProductId { get; set; }
    public decimal Quantity { get; set; }

    public override Order Execute(MyContext container, Order order)
    {
        var detail = new Detail
        {
            Name = ProductId,
            Quantity = Quantity,
        };
        order.Details.Add(detail);
        return order;
    }
}
...etc

So, what happened here?
We have created a single operation, Execute, that receives a sequence of “commands”.
Each command is modeled as a subclass of “Command”.
This enables us to send a sequence of commands and process them all in the same transaction.

We have captured language, intentions, and each command can easily be tested.
And as a bonus, it doesn’t suffer from the weird mapping problems that the DTO approach suffers from.

Another nice aspect of this is that if we want to edit a few details of a large object, e.g. we want to change quantity of a single product in an order of 100 order details, we can send a single command.

So to sum it up, pros:

  • Captured domain language
  • Explicit state transitions
  • Network effective
  • Testable
  • Easy to implement, no odd change tracking problems like using the DTO approach
  • Extensible, we can easily add new commands to the existing pipeline w/o adding more service operations

Cons:

  • Verbose
  • Puts somewhat more responsibility on the client

The code in this example can of-course be improved, we are using an anemic domain model right now, but the essence of the command pattern can be seen here.

I will post a more “correct” implementation in my next post

That’s all for now