You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-functions/durable/durable-functions-checkpointing-and-replay.md
+5-14Lines changed: 5 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,8 +3,7 @@ title: Checkpoints and replay in Durable Functions - Azure
3
3
description: Learn how checkpointing and reply works in the Durable Functions extension for Azure Functions.
4
4
services: functions
5
5
author: ggailey777
6
-
manager: jeconnoc
7
-
keywords:
6
+
manager: gwallace
8
7
ms.service: azure-functions
9
8
ms.topic: conceptual
10
9
ms.date: 12/07/2018
@@ -123,17 +122,9 @@ The replay behavior creates constraints on the type of code that can be written
123
122
124
123
If orchestrator code needs to get the current date/time, it should use the [CurrentUtcDateTime](https://azure.github.io/azure-functions-durable-extension/api/Microsoft.Azure.WebJobs.DurableOrchestrationContext.html#Microsoft_Azure_WebJobs_DurableOrchestrationContext_CurrentUtcDateTime) (.NET) or `currentUtcDateTime` (JavaScript) API, which is safe for replay.
125
124
126
-
If orchestrator code needs to generate a random GUID, it should use the [NewGuid](https://azure.github.io/azure-functions-durable-extension/api/Microsoft.Azure.WebJobs.DurableOrchestrationContext.html#Microsoft_Azure_WebJobs_DurableOrchestrationContext_NewGuid) (.NET) API, which is safe for replay, or delegate GUID generation to an activity function (JavaScript), as in this example:
125
+
If orchestrator code needs to generate a random GUID, it should use either the [NewGuid](https://azure.github.io/azure-functions-durable-extension/api/Microsoft.Azure.WebJobs.DurableOrchestrationContext.html#Microsoft_Azure_WebJobs_DurableOrchestrationContext_NewGuid) (.NET) or the `newGuid`(JavaScript) API, which is safe for replay.
127
126
128
-
```javascript
129
-
constuuid=require("uuid/v1");
130
-
131
-
module.exports=asyncfunction(context) {
132
-
returnuuid();
133
-
}
134
-
```
135
-
136
-
Non-deterministic operations must be done in activity functions. This includes any interaction with other input or output bindings. This ensures that any non-deterministic values will be generated once on the first execution and saved into the execution history. Subsequent executions will then use the saved value automatically.
127
+
Other than these special cases, non-deterministic operations must be done in activity functions. This includes any interaction with other input or output bindings. This ensures that any non-deterministic values will be generated once on the first execution and saved into the execution history. Subsequent executions will then use the saved value automatically.
137
128
138
129
* Orchestrator code should be **non-blocking**. For example, that means no I/O and no calls to `Thread.Sleep` (.NET) or equivalent APIs.
139
130
@@ -160,7 +151,7 @@ While these constraints may seem daunting at first, in practice they aren't hard
160
151
161
152
Tasks that can be safely awaited in orchestrator functions are occasionally referred to as *durable tasks*. These are tasks that are created and managed by the Durable Task Framework. Examples are the tasks returned by `CallActivityAsync`, `WaitForExternalEvent`, and `CreateTimer`.
162
153
163
-
These *durable tasks* are internally managed by using a list of `TaskCompletionSource` objects. During replay, these tasks get created as part of orchestrator code execution and are completed as the dispatcher enumerates the corresponding history events. This is all done synchronously using a single thread until all the history has been replayed. Any durable tasks, which are not completed by the end of history replay has appropriate actions carried out. For example, a message may be enqueued to call an activity function.
154
+
These *durable tasks* are internally managed by using a list of `TaskCompletionSource` objects. During replay, these tasks get created as part of orchestrator code execution and are completed as the dispatcher enumerates the corresponding history events. This is all done synchronously using a single thread until all the history has been replayed. Any durable tasks that are not completed by the end of history replay have appropriate actions carried out. For example, a message may be enqueued to call an activity function.
164
155
165
156
The execution behavior described here should help you understand why orchestrator function code must never `await` a non-durable task: the dispatcher thread cannot wait for it to complete and any callback by that task could potentially corrupt the tracking state of the orchestrator function. Some runtime checks are in place to try to prevent this.
166
157
@@ -169,4 +160,4 @@ If you'd like more information about how the Durable Task Framework executes orc
169
160
## Next steps
170
161
171
162
> [!div class="nextstepaction"]
172
-
> [Learn about instance management](durable-functions-instance-management.md)
163
+
> [Learn about instance management](durable-functions-instance-management.md)
Copy file name to clipboardExpand all lines: articles/azure-functions/durable/durable-functions-cloud-backup.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -177,4 +177,4 @@ Here is the orchestration as a single C# file in a Visual Studio project:
177
177
This sample has shown how to implement the fan-out/fan-in pattern. The next sample shows how to implement the monitor pattern using [durable timers](durable-functions-timers.md).
178
178
179
179
> [!div class="nextstepaction"]
180
-
> [Run the monitor sample](durable-functions-monitor.md)
180
+
> [Run the monitor sample](durable-functions-monitor.md)
@@ -53,7 +72,7 @@ public static async Task<object> Run(DurableOrchestrationContext context)
53
72
```
54
73
55
74
> [!NOTE]
56
-
> There are subtle differences between writing a precompiled durable function in C# and writing a precompiled durable function in the C# script that's shown in the example. In a C# precompiled function, durable parameters must be decorated with respective attributes. An example is the `[OrchestrationTrigger]` attribute for the `DurableOrchestrationContext` parameter. In a C# precompiled durable function, if the parameters aren't properly decorated, the runtime can't inject the variables into the function, and an error occurs. For more examples, see the [azure-functions-durable-extension samples on GitHub](https://github.com/Azure/azure-functions-durable-extension/blob/master/samples).
75
+
> There are subtle differences between writing a precompiled durable function in C# and writing a precompiled durable function in C# script. In a C# precompiled function, durable parameters must be decorated with respective attributes. An example is the `[OrchestrationTrigger]` attribute for the `DurableOrchestrationContext` parameter. In a C# precompiled durable function, if the parameters aren't properly decorated, the runtime can't inject the variables into the function, and an error occurs. For more examples, see the [azure-functions-durable-extension samples on GitHub](https://github.com/Azure/azure-functions-durable-extension/blob/master/samples).
57
76
58
77
#### JavaScript (Functions 2.x only)
59
78
@@ -85,6 +104,29 @@ With normal functions, you can fan out by having the function send multiple mess
85
104
86
105
The Durable Functions extension handles this pattern with relatively simple code:
@@ -351,6 +470,20 @@ To create the durable timer, call `context.CreateTimer` (.NET) or `context.df.cr
351
470
352
471
An external client can deliver the event notification to a waiting orchestrator function by using either the [built-in HTTP APIs](durable-functions-http-api.md#raise-event) or by using the [DurableOrchestrationClient.RaiseEventAsync](https://azure.github.io/azure-functions-durable-extension/api/Microsoft.Azure.WebJobs.DurableOrchestrationClient.html#Microsoft_Azure_WebJobs_DurableOrchestrationClient_RaiseEventAsync_System_String_System_String_System_Object_) API from another function:
Copy file name to clipboardExpand all lines: articles/azure-functions/durable/durable-functions-diagnostics.md
+38-4Lines changed: 38 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -153,9 +153,26 @@ The result is a list of instance IDs and their current runtime status.
153
153
154
154
It's important to keep the orchestrator replay behavior in mind when writing logs directly from an orchestrator function. For example, consider the following orchestrator function:
If you want to only log on non-replay execution, you can write a conditional expression to log only if `IsReplaying` is `false`. Consider the example above, but this time with replay checks.
if (!context.IsReplaying) log.LogInformation("Calling F1.");
234
+
awaitcontext.CallActivityAsync("F1");
235
+
if (!context.IsReplaying) log.LogInformation("Calling F2.");
236
+
awaitcontext.CallActivityAsync("F2");
237
+
if (!context.IsReplaying) log.LogInformation("Calling F3");
238
+
awaitcontext.CallActivityAsync("F3");
239
+
log.LogInformation("Done!");
240
+
}
241
+
```
242
+
209
243
#### C#
210
244
211
245
```cs
@@ -252,7 +286,7 @@ Done!
252
286
253
287
Custom orchestration status lets you set a custom status value for your orchestrator function. This status is provided via the HTTP status query API or the `DurableOrchestrationClient.GetStatusAsync` API. The custom orchestration status enables richer monitoring for orchestrator functions. For example, the orchestrator function code can include `DurableOrchestrationContext.SetCustomStatus` calls to update the progress for a long-running operation. A client, such as a web page or other external system, could then periodically query the HTTP status query APIs for richer progress information. A sample using `DurableOrchestrationContext.SetCustomStatus` is provided below:
0 commit comments