Service Fabric SDK v1.5.175 and the adoption of Virtual Machine Scale Sets


Today, we are announcing an update to our preview SDK and the adoption of Virtual Machine Scale Sets in Azure-hosted clusters. As part of this release, we are making a series of changes based on your feedback, some of which are breaking. Please read the notes below carefully to understand what you need to do to adopt the new release.

 

SDK Update

This release of the SDK includes a number of new features, along with some key bug fixes and general performance and reliability improvements.

Windows 7 Support for Development

We heard you loud and clear on the need for Windows 7 support for development machines. Starting with this release, you can run a local cluster and deploy applications to it from Visual Studio 2015 on Windows 7.

Important notes:

  1. There is a bug impacting the Visual Studio debugger for Service Fabric applications on Windows 7. To fix it, you will need to install the Visual Studio 2015 Update 2 CTP.
  2. The Service Fabric PowerShell cmdlets require PowerShell 3.0 or higher, whereas Windows 7 includes PowerShell 2.0 by default. If you have not updated PowerShell to a recent release on your Windows 7 machine, you will need to do so to use the Service Fabric SDK.

 

Delete actors

The Reliable Actors framework includes a form of garbage collection that serializes actor state to disk and then removes the actor object from memory after a period of inactivity. This ensures that you aren’t consuming a large amount of memory in your clusters holding on to actors that are not being used. However, in some cases, you may want to go further than just removing the actors from memory and delete them from the cluster entirely, either to limit storage usage or for compliance. This release adds this capability.

The DeleteActorAsync method can be invoked using ActorServiceProxy as shown below:

var serviceUri = ActorNameFormat.GetFabricServiceUri(typeof(IMyActor), actorAppName);
var actorServiceProxy = ActorServiceProxy.Create(actorId.GetPartitionKey(), serviceUri);
await actorServiceProxy.DeleteActorAsync(actorId, cancellationToken);

Query actors

In order to determine the actors to delete, you’ll probably want to figure out which actors have been created. We have enabled the ability to query the set of actors in a given partition.

This is an Actor Service level operation with following signature:

Task<PagedResult<ActorInformation>> GetActorsAsync(ContinuationToken continuationToken, CancellationToken cancellationToken);

 

This API returns a PagedResult which contains a list of ActorInformation and a continuationToken signifying if more calls are needed to get complete list of actors.

This method can be invoked using ActorServiceProxy as shown below:
 

var serviceUri = ActorNameFormat.GetFabricServiceUri(typeof(IMyActor), actorAppName);
var actorServiceProxy = ActorServiceProxy.Create(partitionKey, serviceUri);
ContinuationToken continuationToken = null;
var queriedActorCount = 0; 

do
{

var queryResult = actorServiceProxy.GetActorsAsync(continuationToken, cancellationToken);
queriedActorCount += queryResult.Items.Count();
continuationToken = queryResult.ContinuationToken;

} while (continuationToken != null);

  

CancellationToken support for IService/IActor

Reliable Service and Reliable Actor methods now support a cancellation token that can be remoted via ActorProxy and ServiceProxy, allowing you to implement cooperative cancellation. Clients that want to cancel a long running service or actor method can signal the cancellation token and that cancellation intent will be propagated to the actor/service method. That method can then determine when to stop execution by looking at the state of its cancellation token argument.

For example, an actor’s contract that has a possibly long-running method can be modelled as shown below:

public interface IPrimeNumberActorInterface : IActor
{

    Task<ulong> FindNextPrimeNumberAsync
        (ulong previous, CancellationToken cancellationToken);

}

The client code that wishes to cancel the method execution can communicate its intent by canceling the cancellation token.

Flexible application packaging for guest executables

Service Fabric can provide orchestration and high-availability for arbitrary executables, referred to as “guest executables”. In some cases, you may want to build an application that is a combination of Reliable Services/Reliable Actors (or “service host executables”) and guest executables. Previously, these types of application packages had to be managed entirely outside of Visual Studio because there was no way to include guest executables in the application package created by VS and msbuild would complain if it found services in the application manifest that did not have a corresponding service project in the solution.

To better support this scenario, the application project now includes an ApplicationPackageRoot folder, similar to the PackageRoot folder found in service projects. The contents of this directory will be directly copied to the generated application package.

Important: as part of this change, the ApplicationManifest file has been moved under the ApplicationPackageRoot folder. Visual Studio will automatically move it as part of project upgrade but you will need to ensure that the move is properly reflected if your project is checked into source control.

 

Key bug fixes

In addition to the features described above, the following key bugs are fixed in this release:

  • An assembly naming clash with Java that was causing FabricHost not to start on some machines with the JRE installed.
  • A long-path issue with the Test-ServiceFabricApplicationPackage PowerShell cmdlet that was causing deployment failures with ASP.NET 5/ASP.NET Core projects.

 

API Breaking Changes

Transaction object now required in IReliableQueue::GetCountAsync

To ensure consistent results, we now provide the count of objects in the queue within transaction scope. To enable this, we require a transaction object to be provided to the GetCountAsync call.

 

IReliableDictionary::Count property replaced by IReliableDictionary::GetCountAsync method

To align with IReliableQueue, IReliableDictionary’s Count property has been replaced with a GetCountAsync method.

 

Reliable collections interfaces no longer implement IEnumerable – use CreateEnumerableAsync instead

In order to prepare for upcoming releases where the data in Reliable Collections may be paged to disk, the ReliableQueue and ReliableDictionary no longer implement IEnumerable directly. Instead, you should use the CreateEnumerableAsync method to acquire an enumerable collection. Note that IEnumerables returned by CreateEnumerableAsync can only be enumerated within transaction scope, so if you intend to use them elsewhere, you will need move the results into a temporary collection, such as a List.

 

Testability APIs moved into System.Fabric assembly and moved namespaces

The testability APIs previously included in the Microsoft.ServiceFabric.Testability NuGet package have now been moved to the System.Fabric assembly and are accessible via the FabricClient type. More specifically, the following methods previously available under System.Fabric.Testability.TestabilityExtensions, are now available via the TestManager and FaultManager properties, as shown below:

Old location (under System.Fabric.Testability.TestabilityExtensions)

New location (under System.Fabric.FabricClient)

InvokeDataLossAsync

TestManager

InvokeQuorumLossAsync

TestManager

RestartPartitionAsync

TestManager

ValidateApplicationAsync

TestManager

ValidateServiceAsync

TestManager

CleanTestStateAsync

TestManager

MovePrimaryAsync

FaultManager

MoveSecondaryAsync

FaultManager

StartNodeAsync

FaultManager

StopNodeAsync

FaultManager

RestartNodeAsync

FaultManager

RemoveReplicaAsync

FaultManager

RestartReplicaAsync

FaultManager

RestartDeployedCodePackageAsync

FaultManager

 

Virtual Machine Scale Sets

In our initial preview release, Service Fabric clusters created in Azure were based on “single-instance virtual machines”, meaning that a specific set of VMs were pre-defined to form the basis of the cluster. Scaling the cluster up or down required that you manually add or remove VMs. Going forward, new Service Fabric clusters will be based on Virtual Machine Scale Sets (VMSS). With VMSS, every node type in your cluster will be tied to a VM scale set, allowing you to define rules for when the number of VMs of that type should grow and shrink. Note that the auto-scaling functionality of VMSS is not integrated with Service Fabric yet and will be enabled in an upcoming release.

 

Updating to the new release

You can install the new SDK using the Web Platform Installer. To take advantage of the new APIs described above in existing projects, you will need to update your NuGet packages to the latest versions.

Important note:

Because of the move to VMSS and the breaking changes in our APIs, we have elected to leave existing clusters in place and fixed on the existing Service Runtime version (4.4.104.9494). If you’re using the existing SDK/NuGet packages (v1.4.87) and targeting those clusters, you can continue to do so. However, in order to deploy apps created with the new SDK or existing apps upgraded to the new NuGet packages to Azure, you will need to create new clusters. Once we reach general availability, this will no longer occur. You can check the version of your cluster in the Azure portal:

 

The following table offers a quick guide to compatibility:

Runtime Version

Compatible SDK/NuGet package version
4.4.x 1.4.87
4.5.x 1.5.175

 

Known Issues

Application project upgrade errors with ASP.NET 5 (aka ASP.NET Core) projects

When you open an existing Service Fabric project with the updated tooling extension included in this SDK, Visual Studio will attempt to upgrade your project to the latest version. Before it does that, it takes the existing contents of your application project folder and moves them to a Backup folder. Given the depth of ASP.NET 5 projects, you may already be close to the limit on path length, so pushing things down another level may cause an error like this:

 

If you hit this, try deleting the auto-generated folders (bin, obj, and pkg) from the application project directory.

 

Questions and feedback

As always, we are monitoring Twitter, StackOverflow, MSDN, Azure.com, and our feedback forum for your comments and questions.


The Service Fabric Team

Comments (12)

  1. Leo says:

    Does Service Fabric support C++? I only see C# examples.

  2. Mark Radcliffe says:

    Is there a way to create an on premises cluster? It was mentioned in previous posts that there would be an update in Q1 that would allow on prem cluster creation.

    1. Alex says:

      Each time you create local dev cluster, you actually create onpremis cluster. Look into C:\Program Files\Microsoft SDKs\Service Fabric\ClusterSetup\DevClusterSetup.ps1, here you can find everything you need for setup any cluster you want (keep trace over references files).

  3. Type resolving issue says:

    I'm using MEF together with Azure Service Fabric. It was working fine  in the 4.4x version. But after I upgrade to v4.5x, it will always throw load exception that System.Fabric.Management.ServiceModel.dll cannot be found and load. Any idea?

    1. Jerome Haltom says:

      I would like to also point out the MEF error. There’s a dependency on one of the 1.5 assemblies to System.Fabric.Management.ServiceModel, which remains unresolved when deployed. Breaking MEF. A simple solution to this is to include that DLL in your project from Program File\Service Fabric. But, that’s pretty non-ideal.

    2. mfussell says:

      Have you established any more details on the what was happening here with MEF?
      Thanks,

  4. Christian Weiss says:

    that's great news! could you please also update the azure quickstart ARM templates to VM Scale Sets?! github.com/…/service-fabric-secure-cluster-5-node-1-nodetype-wad

    thx!

  5. MedAnd says:

    Any examples on DeleteActorAsync?

    1. sivakumar says:

      do you have sample for DeleteActorAsync?

  6. Aashish Koirala says:

    I had a cluster up and running on the previous version that had services listening on HTTPS using OwinCommunicationListener. With the new version, that no longer seems to work. I have not changed any of the LB settings. The port 443 seems to be open, but gets closed as soon as the client tries to talk to it. Any ideas?

    1. Aashish Koirala says:

      I should add – HTTP still works, it’s just HTTPS that has stopped working.

    2. Aashish Koirala says:

      Nevermind, got it working! Apparently you have to explicitly reference the endpoint certificate in the application manifest with this release, whereas you didn’t have to previously. Thanks.

Skip to main content