dapr
/
docs
mirror of https://github.com/dapr/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Added example for limiting workflow concurrency in .NET fan-in/out example (#4132) 

* Added workflow concurrency example for .NET

Signed-off-by: Whit Waldo <whit.waldo@innovian.net>

* Removed extension method that was doubling up calls and shortened to simpler inline example

Signed-off-by: Whit Waldo <whit.waldo@innovian.net>

* Removed unused extension method

Signed-off-by: Whit Waldo <whit.waldo@innovian.net>

* Neglected to include the Task.WhenAll line persisting the remaining result values

Signed-off-by: Whit Waldo <whit.waldo@innovian.net>

* Fixed parallism limit

Signed-off-by: Whit Waldo <whit.waldo@innovian.net>

* Adding proposed concluding thoughts

Co-authored-by: Chris Gillum <cgillum@gmail.com>
Signed-off-by: Whit Waldo <whit.waldo@innovian.net>

* Approved proposed language

Co-authored-by: Chris Gillum <cgillum@gmail.com>
Signed-off-by: Whit Waldo <whit.waldo@innovian.net>

---------

Signed-off-by: Whit Waldo <whit.waldo@innovian.net>
Co-authored-by: Chris Gillum <cgillum@gmail.com>
Co-authored-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com>
This commit is contained in:
Whit Waldo 2024-05-09 13:40:32 -05:00 committed by GitHub
parent 9ba08df562
commit 9055407d99
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 39 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md
View File

@ -586,7 +586,45 @@ The key takeaways from this example are:
- The number of parallel tasks can be static or dynamic
- The workflow itself is capable of aggregating the results of parallel executions
While not shown in the example, it's possible to go further and limit the degree of concurrency using simple, language-specific constructs. Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and only 40 complete before the process crashes, the workflow restarts itself automatically and only schedules the remaining 60 tasks.
Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and only 40 complete before the process crashes, the workflow restarts itself automatically and only schedules the remaining 60 tasks.
It's possible to go further and limit the degree of concurrency using simple, language-specific constructs. The sample code below illustrates how to restrict the degree of fan-out to just 5 concurrent activity executions:
{{< tabs ".NET" >}}
{{% codetab %}}
<!-- .NET -->
```csharp
//Revisiting the earlier example...
// Get a list of N work items to process in parallel.
object[] workBatch = await context.CallActivityAsync<object[]>("GetWorkBatch", null);
const int MaxParallelism = 5;
var results = new List<int>();
var inFlightTasks = new HashSet<Task<int>>();
foreach(var workItem in workBatch)
{
if (inFlightTasks.Count >= MaxParallelism)
{
var finishedTask = await Task.WhenAny(inFlightTasks);
results.Add(finishedTask.Result);
inFlightTasks.Remove(finishedTask);
}
inFlightTasks.Add(context.CallActivityAsync<int>("ProcessWorkItem", workItem));
}
results.AddRange(await Task.WhenAll(inFlightTasks));
var sum = results.Sum(t => t);
await context.CallActivityAsync("PostResults", sum);
```
{{% /codetab %}}
{{< /tabs >}}
Limiting the degree of concurrency in this way can be useful for limiting contention against shared resources. For example, if the activities need to call into external resources that have their own concurrency limits, like a databases or external APIs, it can be useful to ensure that no more than a specified number of activities call that resource concurrently.
## Async HTTP APIs