We are pleased to announce the release of Orleans 3.0. Compared to Orleans 2.0, it has many improvements and fixes, as well as several new features. These changes are dictated by the experience of many people who use Orleans-based applications in production in a wide range of scenarios and environments, as well as the enthusiasm of the global Orleans community, which helps the framework become better, faster and more flexible. Many thanks to everyone who contributed to this release in various ways!
Major changes compared to Orleans 2.0
Orleans 2.0 was released a little over 18 months ago, and the framework has made significant progress since then. Some changes compared to 2.0:
- Distributed ACID Transactions
- A new scheduler that in some cases has increased productivity by more than 30%
- New Roslyn-based Code Generator
- Rewritten cluster membership to improve recovery speed
- Co-hosting support
As well as many other improvements and fixes.
Replacing the network layer with ASP.NET Bedrock
Maintaining secure communications using TLS has been a primary concern for some time. Moreover, both from the community and from internal partners. In version 3.0, we add TLS support, available through the Microsoft.Orleans.Connections.Security package. See the TransportLayerSecurity example for more information.
Implementing TLS support was a major concern due to the way the network layer was implemented in previous versions of Orleans: it could not be easily adapted to use
SslStream
, which is the most common method for implementing TLS. Using TLS as a driving force, we rewrote the Orleans network layer.
In Orleans 3.0, the entire network layer is replaced with a layer created on the basis of Project Bedrock , features of the ASP.NET group. Bedrock's goal is to help developers create fast and reliable network clients and servers.
The ASP.NET team and the Orleans team worked together to create abstractions that support both network clients and servers, are transport-agnostic, and can be configured using middleware. These abstractions allow us to modify the network “transport” through the configuration without changing the internal Orleans-specific network code. Orleans TLS support is implemented as Bedrock middleware, and we intend to make it universal so that it can be shared with others in the .NET ecosystem.
Although the incentive for this innovation was the addition of TLS support, in our nightly load tests, the throughput increases on average by about 30%.
Rewriting the network layer also included replacing our custom buffer pooling with a
MemoryPool<byte>
, and with this change, serialization now takes advantage of
Span<T>
. Some code paths that previously relied on locking through dedicated threads that call
BlockingCollection<T>
now use
Channel<T>
for asynchronous message passing. This results in less dedicated threads, instead moving work to the .NET thread pool.
Co-hosting through Generic Host
Co-hosting Orleans with other platforms such as ASP.NET Core in the same process is now easier than before thanks to the .NET Generic Host .
Here is an example of adding Orleans along with ASP.NET Core to a host using
UseOrleans
:
var host = new HostBuilder() .ConfigureWebHostDefaults(webBuilder => { // ASP.NET Core webBuilder.UseStartup<Startup>(); }) .UseOrleans(siloBuilder => { // Orleans siloBuilder.UseLocalHostClustering(); }) .ConfigureLogging(logging => { /* , */ }) .ConfigureServices(services => { /* */ }) .UseConsoleLifetime() .Build(); // . await host.RunAsync();
This functionality can be used to simplify the deployment topology or to add additional features to an existing application. Some teams use shared hosting internally to add Kubernetes tests to their Orleans projects using ASP.NET Core Health Checks .
Reliability Improvements
Clusters are now faster in recovering from failures thanks to advanced gossiping. In addition, messaging errors are now handled more consistently, as a result of which errors are passed back to the caller. This helps developers find bugs faster. For example, when a message cannot be completely serialized or deserialized, a detailed exception will be passed back to the original caller.
Enhanced Extensibility
Streams can now have their own data adapters, which allows them to receive data in any format. This gives developers more control over how flow items are represented in the repository. It also gives the stream provider control over how data is written, allowing streams to integrate with existing systems and / or non-Orleans services.
The custom state of the transaction can now declare what roles it can play in the transaction. For example, the implementation of a transaction state that writes transaction life cycle events to the service bus queue cannot fulfill the duties of a transaction manager because it is write-only.
Join now!
Now that Orleans 3.0 has been released, we are turning our attention to future releases - and we have some exciting plans! Join our warm and welcoming community on GitHub .
See also: 7 free developer courses