Introducing Akka.NET


akkanet

There are a lot of things going on right now.
First, Pigeon Framework now has a new name; Akka.NET.
We got OK from Typesafe to use the name since we are a pure port of real Akka.

We are also doing a lot of work on the core and remote libs.
We now have a real EndpointManager actor managing transports.
And we have and Endpoint actor for each active endpoint.
Thus, we now support multiple transports, even if only Tcp is provided out of the box right now.

There have been some progress on Routers too.
We now support “Group” routers, e.g. RoundRobinGroup and ConsistentHashingGroup.
“Pool” router support is currently being developed.

Another nice feature we have ported is remote deployment.
This is IMO maybe the coolest feature we have ported so far, this means that we can now via configuration decide if an actor should be deployed locally or remote.
If remote deployment is used, the local actor system will send a message to the remote system, telling it to create the given actor with all of its configuration on the remote node.

For more info see: https://github.com/rogeralsing/Pigeon

Massive improvements to Pigeon – Akka Actors for .NET


The last few weeks have been busy busy.
Me and Aaron have been making some massive improvements to Pigeon.
Most of the Akka features are now completed, remoting still needs some love and after that we will start porting Akka clustering.

One of the latest features we have added is logging.
We support the same features as real Akka, so logging can be done using the ActorSystem.EventStream, and there is also a BusLogging LoggingAdapter.

We are also leveraging the real Akka config, so we can enable logging based on the same configuration options that Akka has.
Here is a snapshot of the output from the StandardOutLogger when booting the ChatServer example:

2014-02-21 22:40:44 DebugLevel EventStream - subscribing [akka://all-systems/StandardOutLogger] to channel Pigeon.Event.Info [Thread 9]
2014-02-21 22:40:44 DebugLevel EventStream - subscribing [akka://all-systems/StandardOutLogger] to channel Pigeon.Event.Warning [Thread 9]
2014-02-21 22:40:44 DebugLevel EventStream - subscribing [akka://all-systems/StandardOutLogger] to channel Pigeon.Event.Error [Thread 9]
2014-02-21 22:40:44 DebugLevel EventStream - StandardOutLogger started [Thread 9]
2014-02-21 22:40:44 DebugLevel akka.tcp://MyServer@localhost:8081 - now supervising akka.tcp://MyServer@localhost:8081/user [Thread 10]
2014-02-21 22:40:44 DebugLevel akka.tcp://MyServer@localhost:8081 - now supervising akka.tcp://MyServer@localhost:8081/system [Thread 10]
2014-02-21 22:40:44 DebugLevel akka.tcp://MyServer@localhost:8081/system - now supervising akka.tcp://MyServer@localhost:8081/system/deadLetterListener [Thread 11]
2014-02-21 22:40:44 DebugLevel EventStream - subscribing [akka.tcp://MyServer@localhost:8081/system/deadLetterListener] to channel Pigeon.Event.DeadLetter [Thread 9]
2014-02-21 22:40:44 DebugLevel akka.tcp://MyServer@localhost:8081/system - now supervising akka.tcp://MyServer@localhost:8081/system/logMyServer-DefaultLogger [Thread 10]
2014-02-21 22:40:44 DebugLevel EventStream(MyServer) - Default Loggers started [Thread 11]
2014-02-21 22:40:44 DebugLevel EventStream - subscribing [akka.tcp://MyServer@localhost:8081/system/logMyServer-DefaultLogger] to channel Pigeon.Event.Error [Thread 11]
2014-02-21 22:40:44 DebugLevel EventStream - unsubscribing [akka.tcp://MyServer@localhost:8081/system/logMyServer-DefaultLogger] from channel Pigeon.Event.Debug [Thread 11]
2014-02-21 22:40:44 DebugLevel EventStream - unsubscribing [akka.tcp://MyServer@localhost:8081/system/logMyServer-DefaultLogger] from channel Pigeon.Event.Info [Thread 11]
2014-02-21 22:40:44 DebugLevel EventStream - unsubscribing [akka.tcp://MyServer@localhost:8081/system/logMyServer-DefaultLogger] from channel Pigeon.Event.Warning [Thread 11]
2014-02-21 22:40:44 WarningLevel ActorSystem(MyServer) - {
  akka : {
    log-config-on-start : on
    stdout-loglevel : DEBUG
    loglevel : ERROR
    actor : {
      provider : "Pigeon.Remote.RemoteActorRefProvider, Pigeon.Remote"
      debug : {
        receive : on
        autoreceive : on
        lifecycle : on
        event-stream : on
        unhandled : on
      }
    }
    remote : {
      server : {
        host : localhost
        port : 8081
      }
    }
  }
} [Thread 9]
2014-02-21 22:40:44 DebugLevel akka.tcp://MyServer@localhost:8081/user - now supervising akka.tcp://MyServer@localhost:8081/user/ChatServer [Thread 10]
2014-02-21 22:40:45 DebugLevel akka.tcp://MyServer@localhost:8081/user/ChatServer - received handled message ChatMessages.ConnectRequest [Thread 11]

Alot of the existing features have also been refined to conform even more to real Akka, e.g. ActorSelection have been rewritten to behave exactly like in Akka.
ActorRefs are now also serializable in messages, so you can send messages containing actorrefs across the wire and use them on remote systems.
The Akka RemoteDaemon is also coming along nicely, so we can create actors on remote nodes this way, the underlying deployment features are however not completed yet.

The Props class have also gotten new features, we can now configure dispatchers and mailboxes via the config and there is also a new dispatcher that lets you run actors in the main thread, to allow GUI updates in WPF/WinForms.

Well, there are alot of new features and bugfixes, so if you are interested in Actor Model Programming in .NET be sure to check out the Pigeon repository at https://github.com/rogeralsing/Pigeon

//Roger

 

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 :)

C# – Consume non-async API’s as async


Now that we have the new nifty async support built into C# you might wonder how you can access your old API’s as if they were async.

Now before I show any code, I have to warn that the code posted here will only wrap your existing sync methods as a Task of T.
You will be able to consume them as if they were async, and in some cases this might be enough, and in other cases, such as IO scenarios, you really should rewrite the methods to use the proper async versions of the IO methods.

The wrapper code provided here may still be a decent start for you to do this, since you can start migrating code to use async calls, while you rewrite the methods that need rewriting later.


    class Program
    {
        static void Main(string[] args)
        {
            Consumer();
            Console.WriteLine("----");
            Console.ReadLine();
        }


        private async static void Consumer()
        {
            //consume the sync method as if it was async
            var b = await Wrap(() => NonAsyncMethod(1, ""));
            Console.WriteLine("got result back {0}",b);
        }

        //this might be one of your old or 3rd party methods
        private static int NonAsyncMethod(int a, string b)
        {
            System.Threading.Thread.Sleep(2000); //emulate some slow code
            return 5;
        }

        private static Task<T> Wrap<T>(Func<T> selector)
        {
            return Task.Factory.StartNew(selector);
        }
    }

Fake Fibers using Async CTP


This is another PoC, building recursive code with continuations using the Async CTP.

The code creates a fake fiber, which can be suspended and resumed, thus allowing us to “step” through its actions.
This technique could be useful when building an interpreting language where you might want to step through the expressions.

    using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Threading;
using System.Runtime.CompilerServices;


namespace ConsoleApplication7
{
    class Program
    {
        static void Main(string[] args)
        {
            FakeFiber f = new MyFiber();

            f.Run();
            while (true)
            {
                //tell fiber to continue
                f.Continue();
                Console.ReadLine();
            }
        }
    }

    public class MyFiber : FakeFiber
    {

        //recursive loop that never throws stack overflow
        async void DoLoop(int count)
        {
            await Yield(); //clear callstack

            Console.WriteLine("{0} {1}", count, System.Threading.Thread.CurrentThread.ManagedThreadId); 
            
            //we can fetch values from other functions too
            //w/o blowing the call stack
            var i = await IntFunc();
            
            Console.WriteLine("got func result {0}",i);
                     
            if (count == 0)
                return;

            DoLoop(count - 1);
        }

        private async Task<int> IntFunc()
        {
            await Yield(); //clear callstack
            return 1;
        }

        public override void Run()
        {
            DoLoop(100000);
        }
    }

    public abstract class FakeFiber
    {
        public abstract void Run();
        private Task currentTask;
        public bool IsCompleted = false;
        public void Continue()
        {
            var task = currentTask;
            if (task != null)
            {
                task.Start();
                task.Wait();
            }
        }

        protected Task Yield()
        {
            currentTask = new Task(() => { this.currentTask = null; });
            return currentTask;
        }
    }
}