First published on MSDN on Sep 13, 2016
Today, we are releasing Service Fabric SDK v2.2.207 and Runtime v5.2.207. This release includes a number of new features, along with a set of important bug fixes. You can get the updated SDK from the links below:
The Service Fabric tools for Visual Studio are not yet compatible with recent changes to the installer for Visual Studio "15" preview. As a result, we are not providing those tools with this release. They will be added back in an upcoming release.
Load metrics in Service Fabric Explorer
In Service Fabric Explorer, we have created a tab to show capacity and load metrics in your Service Fabric cluster. In this first release, we support showing the load of any given metric per node, helping you identify how much capacity is being used across the cluster and on each node.
Actor dependency injection
This release introduces actor constructor dependency injection for Service Fabric platform dependencies, including ActorService, ActorId, and IActorStateManager – the interface implemented by an actor's
ReliableConcurrentQueue is a new a reliable collection of persisted, replicated values that allows concurrent reads and writes with best-effort first-in first-out ordering. Intended as an alternative to IReliableQueue for workloads where strict ordering is not required, as by relaxing the ordering constraint, concurrency can be greatly improved. While IReliableQueue restricts concurrent consumers and producers to a maximum of one each, ReliableConcurrentQueue imposes no such restriction, allowing multiple concurrent consumers and producers.
1-Node local cluster for faster debugging
The default local cluster configuration is made up of five nodes and matches most of the default values found in a multi-machine cluster hosted in Azure. That's great for validating how your services perform when spread across multiple nodes and how they deal with upgrades or failovers. However, it does have a tendency to slow down local development as every debug session involves copying your application package multiple times and waiting for services to start up across multiple nodes using cluster configurations that are tuned for safety rather than speed. Rather than compromise the high fidelity experience, we're introducing a new local development mode based on a 1-node cluster, which has been optimized for speed. We recommend using the 1-node mode while you're primarily focusing on your own business logic and then switching to 5-node when you want to do more thorough testing, including upgrades and failover.
For more details on these features and others, along with bug fixes and known issues, please see the
detailed release notes