Akka.Hosting
1.5.3
Prefix Reserved
See the version list below for details.
dotnet add package Akka.Hosting --version 1.5.3
NuGet\Install-Package Akka.Hosting -Version 1.5.3
<PackageReference Include="Akka.Hosting" Version="1.5.3" />
paket add Akka.Hosting --version 1.5.3
#r "nuget: Akka.Hosting, 1.5.3"
// Install Akka.Hosting as a Cake Addin #addin nuget:?package=Akka.Hosting&version=1.5.3 // Install Akka.Hosting as a Cake Tool #tool nuget:?package=Akka.Hosting&version=1.5.3
Akka.Hosting
This package is now stable.
HOCON-less configuration, application lifecycle management, ActorSystem
startup, and actor instantiation for Akka.NET.
Supported Packages
Consists of the following packages:
Akka.Hosting
- the coreAkka.Hosting
package, needed for everythingAkka.Remote.Hosting
- enables Akka.Remote configuration. Documentation can be read hereAkka.Cluster.Hosting
- used for Akka.Cluster, Akka.Cluster.Sharding, and Akka.Cluster.Tools. Documentation can be read hereAkka.Persistence.Hosting
- used for adding persistence functionality to perform local database-less testing. Documentation can be read hereAkka.Persistence.SqlServer.Hosting
- used for Akka.Persistence.SqlServer support. Documentation can be read hereAkka.Persistence.PostgreSql.Hosting
- used for Akka.Persistence.PostgreSql support. Documentation can be read hereAkka.Persistence.Azure.Hosting
- used for Akka.Persistence.Azure support. Documentation can be read hereAkka.HealthCheck
- Embed health check functionality for environments such as Kubernetes, ASP.NET, AWS, Azure, Pivotal Cloud Foundry, and more. Documentation can be read here- The
Akka.Management
Project Repository - useful tools for managing Akka.NET clusters running inside containerized or cloud based environment.Akka.Hosting
is embedded in each of its packages:Akka.Management
- core module of the management utilities which provides a central HTTP endpoint for Akka management extensions. Documentation can be read hereAkka.Management.Cluster.Bootstrap
- used to bootstrap a cluster formation inside dynamic deployment environments. Documentation can be read hereNOTE
As of version 1.0.0, cluster bootstrap came bundled with the core
Akka.Management
NuGet package and are part of the default HTTP endpoint forAkka.Management
. AllAkka.Management.Cluster.Bootstrap
NuGet package versions below 1.0.0 should now be considered deprecated.Akka.Discovery.AwsApi
- provides dynamic node discovery service for AWS EC2 environment. Documentation can be read hereAkka.Discovery.Azure
- provides a dynamic node discovery service for Azure PaaS ecosystem. Documentation can be read hereAkka.Discovery.KubernetesApi
- provides a dynamic node discovery service for Kubernetes clusters. Documentation can be read hereAkka.Coordination.KubernetesApi
- provides a lease-based distributed lock mechanism backed by Kubernetes CRD for Akka.NET Split Brain Resolver, Akka.Cluster.Sharding, and Akka.Cluster.Singleton. Documentation can be read hereAkka.Coordination.Azure
- provides a lease-based distributed lock mechanism backed by Microsoft Azure Blob Storage for Akka.NET Split Brain Resolver, Akka.Cluster.Sharding, and Akka.Cluster.Singleton. Documentation can be read here
See the "Introduction to Akka.Hosting - HOCONless, "Pit of Success" Akka.NET Runtime and Configuration" video for a walkthrough of the library and how it can save you a tremendous amount of time and trouble.
Summary
We want to make Akka.NET something that can be instantiated more typically per the patterns often used with the Microsoft.Extensions.Hosting APIs that are common throughout .NET.
using Akka.Hosting;
using Akka.Actor;
using Akka.Actor.Dsl;
using Akka.Cluster.Hosting;
using Akka.Remote.Hosting;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAkka("MyActorSystem", configurationBuilder =>
{
configurationBuilder
.WithRemoting("localhost", 8110)
.WithClustering(new ClusterOptions(){ Roles = new[]{ "myRole" },
SeedNodes = new[]{ Address.Parse("akka.tcp://MyActorSystem@localhost:8110")}})
.WithActors((system, registry) =>
{
var echo = system.ActorOf(act =>
{
act.ReceiveAny((o, context) =>
{
context.Sender.Tell($"{context.Self} rcv {o}");
});
}, "echo");
registry.TryRegister<Echo>(echo); // register for DI
});
});
var app = builder.Build();
app.MapGet("/", async (context) =>
{
var echo = context.RequestServices.GetRequiredService<ActorRegistry>().Get<Echo>();
var body = await echo.Ask<string>(context.TraceIdentifier, context.RequestAborted).ConfigureAwait(false);
await context.Response.WriteAsync(body);
});
app.Run();
No HOCON. Automatically runs all Akka.NET application lifecycle best practices behind the scene. Automatically binds the ActorSystem
and the ActorRegistry
, another new 1.5 feature, to the IServiceCollection
so they can be safely consumed via both actors and non-Akka.NET parts of users' .NET applications.
This should be open to extension in other child plugins, such as Akka.Persistence.SqlServer
:
builder.Services.AddAkka("MyActorSystem", configurationBuilder =>
{
configurationBuilder
.WithRemoting("localhost", 8110)
.WithClustering(new ClusterOptions()
{
Roles = new[] { "myRole" },
SeedNodes = new[] { Address.Parse("akka.tcp://MyActorSystem@localhost:8110") }
})
.WithSqlServerPersistence(builder.Configuration.GetConnectionString("sqlServerLocal"))
.WithShardRegion<UserActionsEntity>("userActions", s => UserActionsEntity.Props(s),
new UserMessageExtractor(),
new ShardOptions(){ StateStoreMode = StateStoreMode.DData, Role = "myRole"})
.WithActors((system, registry) =>
{
var userActionsShard = registry.Get<UserActionsEntity>();
var indexer = system.ActorOf(Props.Create(() => new Indexer(userActionsShard)), "index");
registry.TryRegister<Index>(indexer); // register for DI
});
})
Dependency Injection Outside and Inside Akka.NET
One of the other design goals of Akka.Hosting is to make the dependency injection experience with Akka.NET as seamless as any other .NET technology. We accomplish this through two new APIs:
- The
ActorRegistry
, a DI container that is designed to be populated withType
s for keys andIActorRef
s for values, just like theIServiceCollection
does for ASP.NET services. - The
IRequiredActor<TKey>
- you can place this type the constructor of any DI'd resource and it will automatically resolve a reference to the actor stored inside theActorRegistry
withTKey
. This is how we inject actors into ASP.NET, SignalR, gRPC, and other Akka.NET actors!
N.B. The
ActorRegistry
and theActorSystem
are automatically registered with theIServiceCollection
/IServiceProvider
associated with your application.
Registering Actors with the ActorRegistry
As part of Akka.Hosting, we need to provide a means of making it easy to pass around top-level IActorRef
s via dependency injection both within the ActorSystem
and outside of it.
The ActorRegistry
will fulfill this role through a set of generic, typed methods that make storage and retrieval of long-lived IActorRef
s easy and coherent:
- Fetch ActorRegistry from ActorSystem manually
var registry = ActorRegistry.For(myActorSystem);
- Provided by the actor builder
builder.Services.AddAkka("MyActorSystem", configurationBuilder =>
{
configurationBuilder
.WithActors((system, actorRegistry) =>
{
var actor = system.ActorOf(Props.Create(() => new MyActor));
actorRegistry.TryRegister<MyActor>(actor); // register actor for DI
});
});
- Obtaining the
IActorRef
manually
var registry = ActorRegistry.For(myActorSystem);
registry.Get<Index>(); // use in DI
Injecting Actors with IRequiredActor<TKey>
Suppose we have a class that depends on having a reference to a top-level actor, a router, a ShardRegion
, or perhaps a ClusterSingleton
(common types of actors that often interface with non-Akka.NET parts of a .NET application):
public sealed class MyConsumer
{
private readonly IActorRef _actor;
public MyConsumer(IRequiredActor<MyActorType> actor)
{
_actor = actor.ActorRef;
}
public async Task<string> Say(string word)
{
return await _actor.Ask<string>(word, TimeSpan.FromSeconds(3));
}
}
The IRequiredActor<MyActorType>
will cause the Microsoft.Extensions.DependencyInjection mechanism to resolve MyActorType
from the ActorRegistry
and inject it into the IRequired<Actor<MyActorType>
instance passed into MyConsumer
.
The IRequiredActor<TActor>
exposes a single property:
public interface IRequiredActor<TActor>
{
/// <summary>
/// The underlying actor resolved via <see cref="ActorRegistry"/> using the given <see cref="TActor"/> key.
/// </summary>
IActorRef ActorRef { get; }
}
By default, you can automatically resolve any actors registered with the ActorRegistry
without having to declare anything special on your IServiceCollection
:
using var host = new HostBuilder()
.ConfigureServices(services =>
{
services.AddAkka("MySys", (builder, provider) =>
{
builder.WithActors((system, registry) =>
{
var actor = system.ActorOf(Props.Create(() => new MyActorType()), "myactor");
registry.Register<MyActorType>(actor);
});
});
services.AddScoped<MyConsumer>();
})
.Build();
await host.StartAsync();
Adding your actor and your type key into the ActorRegistry
is sufficient - no additional DI registration is required to access the IRequiredActor<TActor>
for that type.
Resolving IRequiredActor<TKey>
within Akka.NET
Akka.NET does not use dependency injection to start actors by default primarily because actor lifetime is unbounded by default - this means reasoning about the scope of injected dependencies isn't trivial. ASP.NET, by contrast, is trivial: all HTTP requests are request-scoped and all web socket connections are connection-scoped - these are objects have bounded and typically short lifetimes.
Therefore, users have to explicitly signal when they want to use Microsoft.Extensions.DependencyInjection via the IDependencyResolver
interface in Akka.DependencyInjection - which is easy to do in most of the Akka.Hosting APIs for starting actors:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddScoped<IReplyGenerator, DefaultReplyGenerator>();
builder.Services.AddAkka("MyActorSystem", configurationBuilder =>
{
configurationBuilder
.WithRemoting(hostname: "localhost", port: 8110)
.WithClustering(new ClusterOptions{SeedNodes = new []{ "akka.tcp://MyActorSystem@localhost:8110", }})
.WithShardRegion<Echo>(
typeName: "myRegion",
entityPropsFactory: (_, _, resolver) =>
{
// uses DI to inject `IReplyGenerator` into EchoActor
return s => resolver.Props<EchoActor>(s);
},
extractEntityId: ExtractEntityId,
extractShardId: ExtractShardId,
shardOptions: new ShardOptions());
});
The dependencyResolver.Props<MySingletonDiActor>()
call will leverage the ActorSystem
's built-in IDependencyResolver
to instantiate the MySingletonDiActor
and inject it with all of the necessary dependences, including IRequiredActor<TKey>
.
Microsoft.Extensions.Configuration Integration
IConfiguration To HOCON Adapter
The AddHocon
extension method can convert Microsoft.Extensions.Configuration
IConfiguration
into HOCON Config
instance and adds it to the ActorSystem being configured.
- All variable name are automatically converted to lower case.
- All "." (period) in the
IConfiguration
key will be treated as a HOCON object key separator - For environment variable configuration provider:
- "__" (double underline) will be converted to "." (period).
- "_" (single underline) will be converted to "-" (dash).
- If all keys are composed of integer parseable keys, the whole object is treated as an array
Example:
appsettings.json
:
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning"
}
},
"AllowedHosts": "*",
"akka": {
"cluster": {
"roles": [ "front-end", "back-end" ],
"min-nr-of-members": 3,
"log-info": true
}
}
}
Environment variables:
AKKA__ACTOR__TELEMETRY__ENABLED=true
AKKA__CLUSTER__SEED_NODES__0=akka.tcp//mySystem@localhost:4055
AKKA__CLUSTER__SEED_NODES__1=akka.tcp//mySystem@localhost:4056
AKKA__CLUSTER__SEED_NODE_TIMEOUT=00:00:05
Example code:
/*
Both appsettings.json and environment variables are combined
into HOCON configuration:
akka {
actor.telemetry.enabled: on
cluster {
roles: [ "front-end", "back-end" ]
seed-nodes: [
"akka.tcp//mySystem@localhost:4055",
"akka.tcp//mySystem@localhost:4056"
]
min-nr-of-members: 3
seed-node-timeout: 5s
log-info: true
}
}
*/
var host = new HostBuilder()
.ConfigureHostConfiguration(builder =>
{
// Setup IConfiguration to load from appsettings.json and
// environment variables
builder
.AddJsonFile("appsettings.json")
.AddEnvironmentVariables();
})
.ConfigureServices((context, services) =>
{
services.AddAkka("mySystem", (builder, provider) =>
{
// convert IConfiguration to HOCON
var akkaConfig = context.Configuration.GetSection("akka");
builder.AddHocon(akkaConfig, HoconAddMode.Prepend);
});
});
Microsoft.Extensions.Logging Integration
Logger Configuration Support
You can use AkkaConfigurationBuilder
extension method called ConfigureLoggers(Action<LoggerConfigBuilder>)
to configure how Akka.NET logger behave.
Example:
builder.Services.AddAkka("MyActorSystem", configurationBuilder =>
{
configurationBuilder
.ConfigureLoggers(setup =>
{
// Example: This sets the minimum log level
setup.LogLevel = LogLevel.DebugLevel;
// Example: Clear all loggers
setup.ClearLoggers();
// Example: Add the default logger
// NOTE: You can also use setup.AddLogger<DefaultLogger>();
setup.AddDefaultLogger();
// Example: Add the ILoggerFactory logger
// NOTE:
// - You can also use setup.AddLogger<LoggerFactoryLogger>();
// - To use a specific ILoggerFactory instance, you can use setup.AddLoggerFactory(myILoggerFactory);
setup.AddLoggerFactory();
// Example: Adding a serilog logger
setup.AddLogger<SerilogLogger>();
})
.WithActors((system, registry) =>
{
var echo = system.ActorOf(act =>
{
act.ReceiveAny((o, context) =>
{
Logging.GetLogger(context.System, "echo").Info($"Actor received {o}");
context.Sender.Tell($"{context.Self} rcv {o}");
});
}, "echo");
registry.TryRegister<Echo>(echo); // register for DI
});
});
A complete code sample can be viewed here.
Exposed properties are:
LogLevel
: Configure the Akka.NET minimum log level filter, defaults toInfoLevel
LogConfigOnStart
: When set to true, Akka.NET will log the complete HOCON settings it is using at start up, this can then be used for debugging purposes.
Currently supported logger methods:
ClearLoggers()
: Clear all registered logger types.AddLogger<TLogger>()
: Add a logger type by providing its class type.AddDefaultLogger()
: Add the default Akka.NET console logger.AddLoggerFactory()
: Add the newILoggerFactory
logger.
Microsoft.Extensions.Logging.ILoggerFactory Logging Support
You can now use ILoggerFactory
from Microsoft.Extensions.Logging as one of the sinks for Akka.NET logger. This logger will use the ILoggerFactory
service set up inside the dependency injection ServiceProvider
as its sink.
Microsoft.Extensions.Logging Log Event Filtering
There will be two log event filters acting on the final log input, the Akka.NET akka.loglevel
setting and the Microsoft.Extensions.Logging
settings, make sure that both are set correctly or some log messages will be missing.
To set up the Microsoft.Extensions.Logging
log filtering, you will need to edit the appsettings.json
file. Note that we also set the Akka
namespace to be filtered at debug level in the example below.
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information",
"Akka": "Debug"
}
}
}
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net5.0 was computed. net5.0-windows was computed. net6.0 was computed. net6.0-android was computed. net6.0-ios was computed. net6.0-maccatalyst was computed. net6.0-macos was computed. net6.0-tvos was computed. net6.0-windows was computed. net7.0 was computed. net7.0-android was computed. net7.0-ios was computed. net7.0-maccatalyst was computed. net7.0-macos was computed. net7.0-tvos was computed. net7.0-windows was computed. net8.0 was computed. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. |
.NET Core | netcoreapp2.0 was computed. netcoreapp2.1 was computed. netcoreapp2.2 was computed. netcoreapp3.0 was computed. netcoreapp3.1 was computed. |
.NET Standard | netstandard2.0 is compatible. netstandard2.1 was computed. |
.NET Framework | net461 was computed. net462 was computed. net463 was computed. net47 was computed. net471 was computed. net472 was computed. net48 was computed. net481 was computed. |
MonoAndroid | monoandroid was computed. |
MonoMac | monomac was computed. |
MonoTouch | monotouch was computed. |
Tizen | tizen40 was computed. tizen60 was computed. |
Xamarin.iOS | xamarinios was computed. |
Xamarin.Mac | xamarinmac was computed. |
Xamarin.TVOS | xamarintvos was computed. |
Xamarin.WatchOS | xamarinwatchos was computed. |
-
.NETStandard 2.0
- Akka.DependencyInjection (>= 1.5.3)
- Microsoft.Extensions.Configuration (>= 3.0.0)
- Microsoft.Extensions.Hosting (>= 3.0.0)
NuGet packages (24)
Showing the top 5 NuGet packages that depend on Akka.Hosting:
Package | Downloads |
---|---|
Petabridge.Cmd.Host
Host engine for the Petabridge.Cmd CLI for managing Akka.NET apps and clusters. Used to load available commands into the cluster itself. |
|
Akka.Persistence.Hosting
Akka.Persistence Microsoft.Extensions.Hosting support. |
|
Akka.Remote.Hosting
Akka.Remote Microsoft.Extensions.Hosting support. |
|
Akka.Management
Akka cluster management module for Akka.NET |
|
Akka.HealthCheck.Hosting
Package Description |
GitHub repositories (1)
Showing the top 1 popular GitHub repositories that depend on Akka.Hosting:
Repository | Stars |
---|---|
petabridge/akkadotnet-code-samples
Akka.NET professional reference code samples
|
Version | Downloads | Last updated |
---|---|---|
1.5.31.1 | 0 | 11/15/2024 |
1.5.31 | 1,837 | 11/11/2024 |
1.5.30.1 | 8,524 | 10/18/2024 |
1.5.30 | 13,039 | 10/3/2024 |
1.5.29 | 4,466 | 10/1/2024 |
1.5.28 | 21,600 | 9/4/2024 |
1.5.27 | 40,862 | 7/29/2024 |
1.5.25 | 68,780 | 6/17/2024 |
1.5.24 | 11,979 | 6/10/2024 |
1.5.22 | 5,401 | 6/4/2024 |
1.5.20 | 24,683 | 4/30/2024 |
1.5.19 | 29,781 | 4/17/2024 |
1.5.18 | 44,492 | 3/14/2024 |
1.5.17.1 | 12,934 | 3/4/2024 |
1.5.16 | 10,704 | 2/23/2024 |
1.5.15 | 86,622 | 1/10/2024 |
1.5.14 | 4,403 | 1/9/2024 |
1.5.13 | 76,996 | 9/27/2023 |
1.5.12.1 | 50,430 | 8/31/2023 |
1.5.12 | 23,751 | 8/3/2023 |
1.5.8.1 | 79,708 | 7/12/2023 |
1.5.8 | 48,985 | 6/21/2023 |
1.5.7 | 51,625 | 5/23/2023 |
1.5.6.1 | 3,800 | 5/17/2023 |
1.5.6 | 6,875 | 5/10/2023 |
1.5.5 | 25,708 | 5/4/2023 |
1.5.4.1 | 5,818 | 5/1/2023 |
1.5.4 | 5,199 | 4/25/2023 |
1.5.3 | 1,330 | 4/25/2023 |
1.5.2 | 20,690 | 4/6/2023 |
1.5.1.1 | 1,878 | 4/4/2023 |
1.5.1 | 23,420 | 3/16/2023 |
1.5.0 | 31,044 | 3/2/2023 |
1.5.0-beta6 | 824 | 3/1/2023 |
1.5.0-beta4 | 454 | 3/1/2023 |
1.5.0-beta3 | 742 | 2/28/2023 |
1.5.0-alpha4 | 763 | 2/17/2023 |
1.0.3 | 13,660 | 2/8/2023 |
1.0.2 | 3,626 | 1/31/2023 |
1.0.1 | 31,354 | 1/6/2023 |
1.0.0 | 5,094 | 12/28/2022 |
0.5.2-beta1 | 3,488 | 11/28/2022 |
0.5.1 | 25,330 | 10/20/2022 |
0.5.0 | 25,560 | 10/4/2022 |
0.4.3 | 24,309 | 9/10/2022 |
0.4.2 | 20,157 | 8/12/2022 |
0.4.1 | 8,205 | 7/21/2022 |
0.4.0 | 3,992 | 7/18/2022 |
0.3.4 | 5,469 | 6/23/2022 |
0.3.3 | 2,966 | 6/16/2022 |
0.3.2 | 2,451 | 6/13/2022 |
0.3.1 | 55,124 | 6/9/2022 |
0.3.0 | 87,414 | 5/24/2022 |
0.2.2 | 9,113 | 4/10/2022 |
0.2.1 | 2,615 | 4/9/2022 |
0.2.0 | 2,457 | 4/9/2022 |
0.1.5 | 2,575 | 4/6/2022 |
0.1.4 | 2,494 | 4/2/2022 |
0.1.3 | 2,136 | 4/1/2022 |
0.1.2 | 2,090 | 3/31/2022 |
0.1.1 | 2,344 | 3/18/2022 |
0.1.0 | 6,465 | 3/10/2022 |
• [Update Akka.NET to 1.5.3](https://github.com/akkadotnet/akka.net/releases/tag/1.5.3)
• [Add SQL transaction isolation level support](https://github.com/akkadotnet/Akka.Hosting/pull/284)
**SQL Transaction Isolation Level Setting**
In 1.5.3, we're introducing fine-grained control over transaction isolation level inside the Akka.Persistence.Hosting, Akka.Persistence.SqlServer.Hosting, and Akka.Persistence.PostgreSql.Hosting plugins.
you can go to the [official Microsoft documentation](https://learn.microsoft.com/en-us/dotnet/api/system.data.isolationlevel?#fields) to read more about these isolation level settings.
Full changelog at https://github.com/akkadotnet/Akka.Hosting/blob/refs/tags/1.5.3/RELEASE_NOTES.md