Service fabric - resilience

Question

I am new to the service industry and started by reviewing MSDN related articles. I started by implementing the Hello World example here .

I changed the original implementation of RunAsync to:

var myDictionary = await this.StateManager.GetOrAddAsync<IReliableDictionary<int, DataObject>>("myDictionary"); while (!cancellationToken.IsCancellationRequested) { DataObject dataObject; using (var tx = this.StateManager.CreateTransaction()) { var result = await myDictionary.TryGetValueAsync(tx, 1); if (result.HasValue) dataObject = result.Value; else dataObject = new DataObject(); // dataObject.UpdateDate = DateTime.Now; // //ServiceEventSource.Current.ServiceMessage( // this, // "Current Counter Value: {0}", // result.HasValue ? result.Value.ToString() : "Value does not exist."); await myDictionary.AddOrUpdateAsync(tx, 1, dataObject, ((k, o) => dataObject)); await tx.CommitAsync(); } await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken); } 

I also introduced the DataObject type and set the UpdateDate property for this type.

 [DataContract(Namespace = "http://www.contoso.com")] public class DataObject { [DataMember] public DateTime UpdateDate { get; set; } } 

When I launch the application (F5 in visual studio 2015), the dataObject instance (with the key as 1) was not found in the dictionary, so I create it, install UpdateDate, add it to the dictionary and commit the transaction. During the next cycle, it finds dataObject (with the key as 1) and sets UpdateDate, updates the object in the dictionary and completes the transaction. Perfect.

Here is my question. When I stop and restart the service project (F5 in visual studio 2015), I would expect a dataObject (with a key like 1) to be found on my first RunAsync iteration, but that is not the case. I expect all states to be reset to his replica.

Do I need to do anything for the state service to clear my internal state to my main replica?

From what I read, it sounds as if all this is being processed by the service fabric and that a commit call (by transaction) is sufficient. If I find the main replica (in the Explorer of Fabric Explorer → Application View), I see that RemoteReplicator_xxx LastACKProcessedTimeUTC is updated after I complete the transaction (when going through it).

Any help is greatly appreciated.

Thanks!

-Mark

Answer 1

This is the default local development feature in Visual Studio. If you carefully look at the output window after pressing F5, you will see the following message:

The deployment script detects that an existing application of the same type and version is already registered, so it removes it and deploys a new one. This deletes the data associated with the old application.

You have several options for solving this problem.

During production, you must upgrade the application to safely deploy updated code while maintaining state. But constantly updating your versions while doing a quick iteration in your dev block can be tedious.

An alternative is to transfer the project property "Save data at the beginning" to "Yes". This will automatically damage all versions of the generated application package (without affecting the versions in your source), and then update the application on your behalf.

Please note that due to some system checks inherent in the upgrade path, this deployment option is likely to be slightly slower than the standard remove-and-replace option. However, when you consider the time required to recreate test data, you often have to erase it.

Answer 2

You need to think of a trusted document as storing collections of objects, not a collection of links. That is, when you add an “object” to the dictionary, you should think that you are completely giving away the object; and you should not change this state of objects anymore. When you request a ReliableDictionary for an "object", it returns a link to your internal object. The link is returned for performance reasons, and you can READ the state of the objects. (It would be nice if the CLR supported read-only objects, but it isn’t.) However, you SHOULD NOT CHANGE the state of objects (or call any methods that would change the state of objects), since you will change the internal data structures of the dictionary that distort his condition.

To change the state of objects, you MUST make a copy of the object that the returned link points to. You can do this by serializing / deserializing the object or in other ways (for example, creating a whole new object and copying the old state to a new object). Then you add the NEW OBJECT to the dictionary. In a future version of Service Fabric, we intend to improve the ReliableDictionarys API to make this required usage model more accessible.