问题标签 [azure-durable-functions]

我有一个持久的函数，它似乎不会崩溃，但在第一次调用后只是继续执行相同的函数。在第一次调用之后尝试设置断点没有任何效果。

我能看到的唯一影响因素似乎是请求有效负载的大小，尽管它低于 65kb 的限制。

它使用文档中描述的扇出/扇入模式。当我的任务数组的大小达到 ~100 时，它似乎停止工作，然后进入无限循环。

也许我已经超过了扇出限制？有没有办法控制函数“实例”的数量？

我正在使用消费计划。

我能找到停止该行为的唯一方法是停止本地存储模拟器并删除并重新初始化底层 localdb。

有没有人有关于进一步排除故障的建议？

我正在玩Azure Durable 功能。目前，我在InvalidOperationException调用活动后进入了编排功能。它抱怨检测到多线程执行。如果协调器函数之前从不受支持的异步回调中恢复，则可能会发生这种情况。

有没有人遇到过这样的问题？我做错了什么？完整代码可以在GitHub上找到

这是编排功能中的一行：

LengthCheck活动函数为：

堆栈跟踪是：

ac6fd5cdd07a4dc9b2577657d65c4f27：函数“InpaintOrchestration（Orchestrator）”，版本“”因错误而失败。原因：System.InvalidOperationException：检测到多线程执行。如果协调器函数之前从不受支持的异步回调中恢复，则可能会发生这种情况。

在 Microsoft.Azure.WebJobs.DurableOrchestrationContext.ThrowIfInvalidAccess()

在 Microsoft.Azure.WebJobs.DurableOrchestrationContext.d__47`1.MoveNext()

从先前抛出异常的位置结束堆栈跟踪

在 System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess（任务任务）

在 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification（任务任务）

在 System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

I have an existing Function App with 2 Functions and a storage queue. F1 is triggered by a message in a service bus topic. For each msg received, F1 calculates some sub-tasks (T1,T2,...) which have to be executed with varying amount of delay. Ex - T1 to be fired after 3 mins, T2 after 5min etc. F1 posts messages to a storage queue with appropriate visibility timeouts (to simulate the delay) and F2 is triggered whenever a message is visible in the queue. All works fine.

I now want to migrate this app to use 'Durable Functions'. F1 now only starts the orchestrator. The orchestrator code is something as follows -

I would only like to fan-out (no fan-in to collect the results) and start the subtasks. The orchestrator starts all the tasks and avoids call 'await Task.WhenAll'. The activity function calls 'Task.Delay' to wait for the specified amount of time and then does its work.

My questions

• Does it make sense to use Durable Functions for this workflow?

• Is this the right approach to orchestrate 'Fan-out' workflow?

• I do not like the fact that the activity function is running for specified amount of time (3 or 5 mins) doing nothing. It will incurs costs,or?

• Also if a delay of more than 10 minutes is required there is no way for an activity function to succeed with this approach!

• My earlier attempt to avoid this was to use 'CreateTimer' in the orchestrator and then add the activity as a continuation, but I see only timer entries in the 'History' table. The continuation does not fire! Am I violating the constraint for orchestrator code - 'Orchestrator code must never initiate any async operation' ?

UPDATE : using approach suggested by Chris

Activity that calculates subtasks and delays

Simply scheduling tasks from within the orchestrator seems to work.In my case I am calculating the tasks and the delays in another activity (CalculateTasks) before the loop. I want the delays to be calculated using the 'current time' when the activity was run. I am using DateTime.UtcNow in the activity. This somehow does not play well when used in the orchestrator. The activities specified by 'ContinueWith' just don't run and the orchestrator is always in 'Running' state.

Can I not use the time recorded by an activity from within the orchestrator?

UPDATE 2

So the workaround suggested by Chris works!

Since I do not want to collect the results of the activities I avoid calling 'await Tasks.WhenAll(tasks)' after scheduling all activities. I do this in order to reduce the contention on the control queue i.e. be able to start another orchestration if reqd. Nevertheless the status of the 'orchestrator' is still 'Running' till all the activities finish running. I guess it moves to 'Complete' only after the last activity posts a 'done' message to the control queue.

Am I right? Is there any way to free the orchestrator earlier i.e right after scheduling all activities?

我正在尝试运行 Microsoft 持久功能示例。文章在这里。当我运行函数项目（C#、Visual Studio）时，它似乎可以正常启动，CLI 启动，我得到了 Host Initialised 并列出了两个启动 URL。

但是，当我导航到一个函数来启动它时，它会告诉我“未找到”，例如：

http://localhost:7071/orchestrators/E1_HelloSequence

我得到“未找到”：

如果让我这么头疼，知道为什么这个最基本的样本吗？我尝试了许多不同的组合，但都无济于事。

我在 Azure 中创建了我的第一个大型持久函数，它为文档的每一页运行大约 12 个活动函数。前几天我最多处理了 5000 页。我知道每个活动都会在工作项 Q 上放置一个项目，所以理论上我写了 60k 队列消息，这些消息也需要阅读，所以这是 120k 动作。

北欧 LRS GPv2 存储为 0.003 英镑/10K 类 2 Q 操作

所以这是 12 * £0.003 = 3.6p 但是我的订阅显示价值超过 90p 的 2 类 Q 操作，这相当于 3M Q 操作或每页 600 个 Q 操作。这大大超过了我在同一时期的消费计划的计算成本，即当天的 29 便士。我很感激还有其他消息需要进入 Q，但没想到这么多！

我是否遗漏了有关 Durable Functions 如何使用 Q 的内容，是否有任何我可以注意或监控的内容来尝试计算单个页面生成的所有 Q（成本）操作，以便我可以弄清楚如何减少它们。

感谢任何见解，因为我喜欢耐用的功能，但存储成本开始变得令人望而却步！我将转向 v1 以降低成本，但仍想了解这一点，以了解这是否只是功能成本，或者我是否在我的功能中做一些低效的事情。

更新 3 可能最有用

我创建了一个新版本，它只接受一个文件，一个活动将其拆分为单页 pdf，然后每个页面由另一个活动处理以转换为 png。我创建了一个新的存储帐户并打开了每个日志记录选项，日志记录被证明是最有用的，我上传了一个 100 页的 PDF，然后当我下载并分析函数运行期间的日志时，我看到以下内容：

大约在 10:31 到 10:43 之间进行处理，在此期间我从日志文件中看到：

除此之外，我让应用程序闲置（在消费计划中），每小时我看到大约：

（这里可能缺少最终日志，我认为它每 10 秒使用每种类型的消息轮询 5 个 Q 中的每一个，因此每小时会进行 3600 个 Q 操作，不知道为什么它需要轮询控制和工作项 Q什么都没有提交处理？）

在我看来，当函数实际执行操作时，会触发大量的 GetMessage 和 GetMessages，查看日志，如果这有助于诊断问题，我可以提供日志。

（如果相关，实例计数在完成时从 0 变为 8，想知道实例与 Q 请求的数量之间是否存在相关性）

更新 1

所以我运行了以下命令，希望能给我当天的所有函数调用：

这给了我总共 19,939 个，这几乎是正确的，因为虽然有多个函数，但我实际处理的大约 3,500 个页面的每个页面只调用其中一些函数。

然后我设法找出如何查询该存储帐户上 Q 的指标，一旦我制定了过滤器，我发现以下是所有 Q 事务的去向：

看起来像一个荒谬的Q阅读量？只是为了检查一下，我还查看了 Q 和 25K 上的消息量似乎大致正确：

我已经转移到 V1 存储帐户，并在今天尝试再次运行大约 8K 页面，因此当它们都过滤到存储帐户的指标时，我会看到指标的外观。

注意：查看图表，我注意到 13 日的数据似乎更合理，我不相信我改变了任何重要的东西，除了可能打开采样以获取应用洞察力，因为这会产生大量数据！

更新 2昨天在新的 v1 存储帐户上看到了同样巨大的 8k ish 页面处理数量。

我有一个持久函数，其输入由前一个活动函数确定。对于每个活动函数，我有多个等待任务，其中每个任务都依赖于前一个任务的输出。

这是我的结构如下：

编排器

活动功能

我已经对此进行了测试，一切正常。但我想知道这是否是好习惯？对于持久功能，在活动功能中具有等待任务是否正常？

我有一个新的持久功能来替换长时间运行的 webjob，它运行良好并且比以前的 webjob 更快，但是我遇到了并行性问题。

我知道所有活动都进入一个中心工作项 Q，这意味着项目按顺序处理，我遇到的问题是，如果用户 A 的积压工作中有 10 个项目并且用户 B 提交了一些东西，那么用户 B 必须等待直到用户 A 的所有数据处理完毕。

使用当前的 webjobs，我们可以自动缩放，一个新的 webjob 将为用户 B 获取数据并与现有处理并行处理。

我是否认为唯一的方法是发布我的功能的 2 个副本，每个用户/客户端一个，以确保一个用户不受另一个用户积压数据的影响？

我尝试将事物分块到工作项 Q 上，因此没有单个任务在 Q 上放置超过 X 个项目，因此理论上会有一些资源共享，但这只会减慢速度，因为工作项 Q 上的内容更少，所以由于工作项 Q 的体积较小，消耗计划自动缩放的扩展非常缓慢。

更新

我应该更清楚为什么我会看到这个问题，大约。Durable Function 流程如下：

• 将文件拆分为页面
• 扇出在每个页面的 Q 上放置一个活动
• 扇入
• 扇出为每个页面在 Q 上放置另一个活动（需要先前扇出的数据才能运行）
• 扇入
• 在单个事务中将页面信息插入数据库
• 将文件标记为在数据库中处理

所以用户 A 加载文件 1 有 1000 页，然后用户 B 加载文件有 100 页。

虽然我很欣赏它并行处理活动 Q，但它仍然按顺序从 Q 中拉出东西（我假设）所以如果用户 B 的文件启动时用户 A 的文件 Q 上有 1000 个项目，那么最初的 100 个页面活动就会得到在 1000 之后执行活动 Q，因此被他们“阻止”。然后，当 100 页初始活动完成时，很有可能下一次对 1000 页文档的扇出将再次向活动 Q 添加更多项目，从而进一步阻止 100 页文档的进度。

我的问题是用户 A 和 B 可能是 2 个不同的客户，他们不希望他们的工作被另一个客户的处理所阻止，因此我对有重复的持久功能实例和在多个实例之间代理消息的评论

这是否更有意义？

我有一个编排函数调用子编排，然后又调用一个活动函数。由于某种原因，活动功能已被多次调用。

“KMA-Orch-DataRefreshOrchestration”->“KMA-Orch-DataRefreshSubOrchestration”->“KMA-Product”

• Azure 运行时版本：1.0
• FUNCTIONS_EXTENSION_VERSION：~1
• 地区 : 美国中部

• 托管计划：标准

• 原触发时间：2018-07-06 08:00:30,989

• 第二次触发：2018-07-06 08:15:41,814
• 第三次触发：2018-07-06 08:43:27,074

Azure Durable Functions 运行时维护一个“历史表”来记录业务流程事件。此表中的一列是“结果”列，用于存储活动函数的返回值。活动函数可以返回“敏感”数据作为中间输出。

成功完成编排后，有没有办法清除此“结果”？是的，也在考虑 GDPR :)

更新：找到一个相关的 github 问题 https://github.com/Azure/azure-functions-durable-extension/issues/17

使用 VSCode + JavaScript 在本地测试 Azure Durable Functions。能够成功触发HTTP触发的Orchestration Client，甚至可以看到请求头+正文没有问题。但是，我在尝试触发 Orchestrator 时收到以下错误：

无法将“Microsoft.Azure.WebJobs.DurableOrchestrationContext”类型的对象转换为“System.String”类型

我不明白为什么 DurableOrchestrationContext 试图变成一个字符串。调用 Orchestrator 的代码：

注意： - 我尝试只发送一个字符串作为输入，但没有效果。- 我已经成功地为另一个项目创建了 Durable Functions，这让这更加令人沮丧。