Akka.net v0.8.0 Release Notes

Release Date: 2015-02-11 // about 9 years ago
  • ๐Ÿ‘ Dependency Injection support for Ninject, Castle Windsor, and AutoFac. Thanks to some amazing effort from individual contributor (@jcwrequests), Akka.NET now has direct dependency injection support for Ninject, Castle Windsor, and AutoFac.

    Here's an example using Ninject, for instance:

    // Create and build your container 
    var container = new Ninject.StandardKernel(); 
    container.Bind().To(typeof(TypedWorker)); 
    container.Bind().To(typeof(WorkerService));
    
    // Create the ActorSystem and Dependency Resolver 
    var system = ActorSystem.Create("MySystem"); 
    var propsResolver = new NinjectDependencyResolver(container,system);
    
    //Create some actors who need Ninject
    var worker1 = system.ActorOf(propsResolver.Create<TypedWorker>(), "Worker1");
    var worker2 = system.ActorOf(propsResolver.Create<TypedWorker>(), "Worker2");
    
    //send them messages
    worker1.Tell("hi!");
    

    ๐Ÿ”Œ You can install these DI plugins for Akka.NET via NuGet - here's how:

    • Ninject - install-package Akka.DI.Ninject
    • Castle Windsor - install-package Akka.DI.CastleWindsor
    • AutoFac - install-package Akka.DI.AutoFac

    ๐Ÿ“š Read the full Dependency Injection with Akka.NET documentation here.

    Persistent Actors with Akka.Persistence (Alpha). Core contributor @Horusiath ported the majority of Akka's Akka.Persistence and Akka.Persistence.TestKit modules.

    ๐Ÿ”ง > Even in the core Akka project these modules are considered to be "experimental," but the goal is to provide actors with a way of automatically saving and recovering their internal state to a configurable durable store - such as a database or filesystem.

    Akka.Persistence also introduces the notion of reliable delivery of messages, achieved through the GuaranteedDeliveryActor.

    ๐Ÿ“ฆ Akka.Persistence also ships with an FSharp API out of the box, so while this package is in beta you can start playing with it either F# or C# from day one.

    ๐Ÿ“ฆ If you want to play with Akka.Persistence, please install any one of the following packages:

    • Akka.Persistence - install-package Akka.Persistence -pre
    • Akka.Persistence.FSharp - install-package Akka.Persistence.FSharp -pre
    • โœ… Akka.Persistence.TestKit - install-package Akka.Persistence.TestKit -pre

    ๐Ÿ“š Read the full Persistent Actors with Akka.NET documentation here.

    ๐Ÿš€ Remote Deployment of Routers and Routees. You can now remotely deploy routers and routees via configuration, like so:

    ๐Ÿš€ Deploying routees remotely via Config:

    actor.deployment {
        /blub {
          router = round-robin-pool
          nr-of-instances = 2
          target.nodes = [""akka.tcp://${sysName}@localhost:${port}""]
        }
    }
    
    var router = masterActorSystem.ActorOf(new RoundRobinPool(2).Props(Props.Create<Echo>()), "blub");
    

    ๐Ÿš€ When deploying a router via configuration, just specify the target.nodes property with a list of Address instances for each node you want to deploy your routees.

    ๐Ÿš€ > NOTE: Remote deployment of routees only works for Pool routers.

    ๐Ÿš€ Deploying routers remotely via Config:

    actor.deployment {
        /blub {
          router = round-robin-pool
          nr-of-instances = 2
          remote = ""akka.tcp://${sysName}@localhost:${port}""
        }
    }
    
    var router = masterActorSystem.ActorOf(Props.Create<Echo>().WithRouter(FromConfig.Instance), "blub");
    

    ๐Ÿš€ Works just like remote deployment of actors.

    ๐Ÿš€ If you want to deploy a router remotely via explicit configuration, you can do it in code like this via the RemoteScope and RemoteRouterConfig:

    ๐Ÿš€ Deploying routees remotely via explicit configuration:

    var intendedRemoteAddress = Address.Parse("akka.tcp://${sysName}@localhost:${port}"
    .Replace("${sysName}", sysName)
    .Replace("${port}", port.ToString()));
    
     var router = myActorSystem.ActorOf(new RoundRobinPool(2).Props(Props.Create<Echo>())
    .WithDeploy(new Deploy(
        new RemoteScope(intendedRemoteAddress.Copy()))), "myRemoteRouter");
    

    ๐Ÿš€ Deploying routers remotely via explicit configuration:

    var intendedRemoteAddress = Address.Parse("akka.tcp://${sysName}@localhost:${port}"
    .Replace("${sysName}", sysName)
    .Replace("${port}", port.ToString()));
    
     var router = myActorSystem.ActorOf(
        new RemoteRouterConfig(
        new RoundRobinPool(2), new[] { new Address("akka.tcp", sysName, "localhost", port) })
        .Props(Props.Create<Echo>()), "blub2");
    

    ๐Ÿ‘Œ Improved Serialization and Remote Deployment Support. All internals related to serialization and remote deployment have undergone vast improvements in order to support the other work that went into this release.

    ๐Ÿ”Œ Pluggable Actor Creation Pipeline. We reworked the plumbing that's used to provide automatic Stash support and exposed it as a pluggable actor creation pipeline for local actors.

    ๐Ÿš€ This release adds the ActorProducerPipeline, which is accessible from ExtendedActorSystem (to be able to configure by plugins) and allows you to inject custom hooks satisfying following interface:

    interface IActorProducerPlugin {
        bool CanBeAppliedTo(ActorBase actor);
        void AfterActorCreated(ActorBase actor, IActorContext context);
        void BeforeActorTerminated(ActorBase actor, IActorContext context);
    }
    
    • CanBeAppliedTo determines if plugin can be applied to specific actor instance.
    • AfterActorCreated is applied to actor after it has been instantiated by an ActorCell and before InitializableActor.Init method will (optionally) be invoked.
    • BeforeActorTerminated is applied before actor terminates and before IDisposable.Dispose method will be invoked (for disposable actors) - auto handling disposable actors is second feature of this commit.

    ๐Ÿ”Œ For common use it's better to create custom classes inheriting from ActorProducerPluginBase and ActorProducerPluginBase<TActor> classes.

    Pipeline itself provides following interface:

    class ActorProducerPipeline : IEnumerable<IActorProducerPlugin> {
        int Count { get; } // current plugins count - 1 by default (ActorStashPlugin)
        bool Register(IActorProducerPlugin plugin)
        bool Unregister(IActorProducerPlugin plugin)
        bool IsRegistered(IActorProducerPlugin plugin)
        bool Insert(int index, IActorProducerPlugin plugin)
    }
    
    • Register - registers a plugin if no other plugin of the same type has been registered already (plugins with generic types are counted separately). Returns true if plugin has been registered.
    • Insert - same as register, but plugin will be placed in specific place inside the pipeline - useful if any plugins precedence is required.
    • Unregister - unregisters specified plugin if it has been found. Returns true if plugin was found and unregistered.
    • IsRegistered - checks if plugin has been already registered.

    0๏ธโƒฃ By default pipeline is filled with one already used plugin - ActorStashPlugin, which replaces stash initialization/unstashing mechanism used up to this moment.

    โœ… MultiNodeTestRunner and Akka.Remote.TestKit. The MultiNodeTestRunner and the Multi Node TestKit (Akka.Remote.TestKit) underwent some drastic changes in this update. They're still not quite ready for public use yet, but if you want to see what the experience is like you can clone the Akka.NET Github repository and run the following command:

    C:\akkadotnet> .\build.cmd MultiNodeTests
    

    โœ… This will automatically launch all MultiNodeSpec instances found inside Akka.Cluster.Tests. We'll need to make this more flexible to be able to run other assemblies that require multinode tests in the future.

    ๐Ÿ— These tests are not enabled by default in normal build runs, but they will at some point in the future.

    Here's a sample of the output from the console, to give you a sense of what the reporting looks like:

    ๐Ÿฑ image

    ๐Ÿš€ The MultiNodeTestRunner uses XUnit internally and will dynamically deploy as many processes are needed to satisfy any individual test. Has been tested with up to 6 processes.