Cancellation Token usage in Service fabric

[balukantu]

I have created a Service Fabric Application. There is a long-running job in the RunAsync() method like "LoadData() which migrates million of records from Database to ServiceFabric dictionary".

As per the MSDN documentation, Services that want to implement a background task, which runs when the service comes up, should override this method with their logic "RunAsync(CancellationToken)"

Cancellation token is used to monitor for cancellation requests and it exists from RunAsync() and shut down the service. So I had used CancellationToken in my project.

Here is my code

`RunAsync (System.Threading.CancellationToken cancellationToken); { LoadData(CancellationToken); }

Async Task LoadData(CancellationToken) { Method1(CancellationToken) -- Aync call Method2() -- Normal call Method3() -- Normal call }`

As you can see, I have Method1, which is an asynchronous call and it runs as a separate thread so the same token is being passed to this method as the main thread will not aware of the child thread. However, Method2 and Method3 are just functional calls so the CancellationToken is not passed because there are running in the context of the main thread.

I have a couple of questions on CancellationToken usage in Service Fabric.

1. Do we need to pass the CancellationToken for all methods that are being called from the Long-running method( Async/ Sync)?
2. The way how I have handled CancellationToken is correct or Do I need to modify anything?

[masnider]

Regarding 2 and 3, it is not required that you pass the token, but if those methods are expected to take any time at all or be long running or do IO that is cancellable (ie: within them have API calls that could, take a cancellation token) then I would also pass them the cancellation token and have them propagate it.

From here we can't see much about how you're actually handling cancellation via the cancellation token - this looks a little like pseudocode. We'll presume inside Method 1 it's handled correctly (watching for the cancellation signal or throwing on cancellation requested, tracking any inflight work and undoing anything that needs to be undone that didn't complete, etc) and that you're awaiting things appropriately or returning Tasks as necessary.

A good exercise to be sure you're doing this all correctly is to start the service and then perform service upgrades that change the code a little. SF will be calling all your service lifecycle methods during that exercise and if they are not implemented correctly the upgrade will be slow and/or fail and produce lots of warnings and errors along the way. Chaos testing via the SF APIs is also a good way to ensure everything is correct.