Introducing Akka.NET


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:

Hotswap and Supervision – Pigeon – Akka Actors for .NET

This is a follow up on my previous post;

The code for this project can be found here:

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)
            .With<Greet>(m => {
                Console.WriteLine("Hello {0}", m.Who);
                //this could also be a lambda

    void OtherReceive(IMessage 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:

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:

Optimizing SOA Applications – C# Async Fork

[Edit 2012-12-04]
Nowdays, there is better paralell support built into .NET itself.
You can replace my old fork code with the following:

//declare the variables we want to assign
string str = null;
int val = 0;

//start a new async fork
//assign the variables inside the fork 

Parallel.Invoke(() => str = CallSomeWebService (123,"abc"),
                () => val = ExecSomeStoredProc ("hello"));

//the fork has finished 

//we can use the variables now
Console.WriteLine("{0} {1}", str, val);




I’m currently developing a site where my domain model is filled with data from both a database and allot of service calls; normal web services and quite a bit of main frame calls.

So I’m accessing data from multiple remote sources, and each call to such source will cost me a bit of time.
If I call them in a synchronous manner, then the time to call each source will be accumulative.
Lets say that I make four remote calls per page request and that each call takes about 0.25 sec, then we would spend a total of 1 sec just waiting for responses.

But if I we spawn a thread per call and then call those services at the same time, we would only have to wait a total of 0.25 sec, thats four times faster than the synchronous way.
The problem is just that .NET does not support any small and clean way to do this (AFAIK)

We can of course use async callbacks and such, but you will have to design your code a certain way to do this and the code will be both bloated and harder to read.

I just want to be able to design my code just as I would when I build a synchronous flow.
So I came up with a small fluent fork API for this.

The API is based on three methods, Begin , Call and End:

  • Begin will spawn a new async fork
  • Call will add the action we want to perform onto a queue
  • End will execute the queue of actions and then wait for all of them to finish.

When the fork is finished, we can be sure that all the calls have completed and we can safely access any variable that was assigned within the fork calls.


//declare the variables we want to assign
string str = null;
int val = 0;

//start a new async fork
//assign the variables inside the fork 

    .Call(() => str = CallSomeWebService (123,"abc") )
    .Call(() => val = ExecSomeStoredProc ("hello") )

//the fork has finished 

//we can use the variables now
Console.WriteLine("{0} {1}", str, val);

We can write the code just like normal, we do not have to redirect our flow to any async callbacks or deal with IAsyncResults or stuff like that.

If you know any easier way to do this, please let me know.
As for now, this is the way I do my async variable assignments.

You can find the C# code for the fork class here: