问题标签 [azure-durable-functions]

在 Azure Durable 上工作时，如果我必须在本地重新启动服务。我收到此错误（快照）-“端口 7071 不可用。使用该端口关闭进程或使用 --port 指定另一个端口”。

为了解决这个问题，我必须在停止服务后等待几​​分钟，然后再启动它。如果它不起作用，我将再等待 2-3 分钟，然后再试一次。尽管该解决方法始终如一，但仍然很痛苦。

任何人都知道更好的解决方案。

假设我有以下编排：

我的所有活动都使用 Azure SQL 数据库，如果任何调用失败，我想撤消以前活动所做的所有更改 - 例如，如果第二次调用Baz引发异常，我想撤消由Foo,Bar如果第一个Baz已经完成，我也想撤消它的修改。

在非函数应用程序中，我可以将整个编排主体包装在一个using scope = new TransactionScope()块中。

这是否适用于潜在的分布式编排，如果没有，Azure Functions 框架中是否有任何类似的机制？或者我是否需要为每个活动编写回滚实现并在完成每个活动后将更改提交到数据库？

我正在尝试实现 Azure Durable Function 工作流。

每隔 6 分钟，我就有一个 Azure TimerTrigger 函数调用一个 Azure 编排函数 (OrchestrationTrigger)，该函数又启动许多活动函数 (ActivityTrigger)。

然而，有时，Orchestration 函数会在几秒钟内被调用两次！这是一个大问题，因为我的活动函数不是幂等的！

下面是我的代码是如何被调用的。

定时器触发功能：

编排功能：

活动功能：

我们有一个从 Azure 调度程序调用的 Azure 函数。这是一个长期运行的功能。我们正在使用持久功能框架。它返回 Azure 调度程序 202 Accepted，回调的位置以检查函数的状态。由于某种原因，Azure 调度程序似乎没有回拨。根据“限制”的文档，如果您的操作时间超过 1 分钟，您将实施“HTTP 异步协议”。这就是我们所做的。我们已经验证了响应标头具有 Location 和 Retry-After 的值。

来自 Docs：HTTP 操作的静态（不可配置）请求超时为 60 秒。对于运行时间较长的操作，请遵循 HTTP 异步协议；例如，立即返回 202 但继续在后台工作。

还有其他人遇到这种行为吗？

我正在尝试使用持久功能进行一些数据转换。为此，我有一个 TimerTriggered 函数，它调用一个编排函数，然后产生转换活动。

我的问题是，当调用 Orchestration 函数时，它会立即产生很多活动，甚至在到达启动该函数的代码部分之前。我的编排功能应该只启动 3 个活动，因为我的 dataList 只包含 3 个元素。

但是可以看出，在我下面包含的日志输出中，在调用了编排函数之后，在包含context.CallActivityAsync的循环开始之前，很多活动函数将立即运行

我根本找不到任何原因。在启动了这么多活动之后，我的循环将实际运行并启动我期望的 3 个活动。

定时器触发功能：

编排功能：

活动功能：

日志输出：

我目前正在开发 Azure 持久功能，但在尝试运行我的功能后，我遇到了未完成的业务流程会在下一次挂起的问题。

问题出在任务中心，正如对这个问题的回答中所解释的那样：

编排已创建，但在之前的运行中未完成。业务流程是持久且长期运行的，因此它们将继续尝试运行，直到它们完成或失败，即使在您关闭函数应用并重新启动它之后也是如此。

现在的问题是，虽然有关于如何在 Azure 上管理任务中心的信息，但我在进行本地测试时找不到任何关于如何管理它的信息。

现在，每次出现问题时我都会更改测试中心的名称，但我更希望有几行代码来简单地清除任务中心中的任何现有数据。

如何在代码中本地管理 Azure 持久功能任务中心？

我想构建一个能够每秒甚至更少从设备接收消息并保持状态的物联网系统。（想想状态机/警报）。

这种情况是 Azure Durable 函数可以使用的，还是我应该采用更经典的方法？特别是考虑延迟和吞吐量。

我目前的架构遇到了一些问题，我不明白为什么......

我有 2 个 Azure Functions 应用程序 (V1) 共享同一个存储帐户。其中一个是消费计划，另一个是应用服务计划。

对于消费计划中的一项功能，我遇到了以下情况：

• 从队列中读取消息
• 取决于阅读，有两种选择：
  1. 使用 StartNewAsync() 方法直接调用 Orchestrator
  2. 在另一个队列中添加消息以在应用服务计划上启动 Orchestrator

我的问题在于第 2 点。

应用服务计划上的 DurableOrchestrationClient 已启动，但似乎 2 个功能应用之间存在问题，因为在 Live Metrics Streams 中我收到很多消息说：

函数“ MyOrchestratorInAppServicePlan ”不存在、被禁用或不是编排器函数。附加信息：以下是活动的协调器函数：' AllTheOrchestratorsIHaveInConsumptionPlan '..InstanceId：601afed81ad64a0aad87bb7984de4a94。功能：MyOrchestratorInAppServicePlan。集线器名称：DurableFunctionsHub。应用名称：MyFunctionAppInConsumptionPlan。插槽名称：生产。扩展版本：1.6.0。序号：47。

而且它们不会定期启动，真正启动所需功能可能需要 30 多分钟，例如消费计划上的功能应用程序正在读取不打算发送给它的消息，而我的应用服务计划功能应用程序什么也不做，因为它已经被另一个“对待”了（我想？）。

任何帮助或建议将不胜感激：D

编辑：我可以通过重新启动两个 Azure Functions 应用程序来启动 Orchestrator，但它并不总是处理所有挂起的持久操作

编辑 2：我刚刚看到它做了同样的事情，但在第 1 点的情况下恢复了。应用服务计划搜索其他持久性而不是消费计划。

I have a durable azure function (2.0) that calls back on itself for an eternal orchestration, based on this article. Code below. This works fine and runs well for approx 20 minutes (say around 50 iterations). However, after this time it goes to sleep and stops working. If I navigate to the Azure portal and just click on the functions app and click the functions list (i.e. I just click around but don't change any settings or stop/start anything) it suddenly "wakes up" and continues on no problem. There are no errors or issues in the logs, just a indication of the inactive period and then the logs resuming. Am I missing a setting somewhere?

After hitting the refresh button as described by @davidebbo the issue still persists, see log below.

Further update, even though the issue on GitHub appears resolved, I still needed to do the double config setting as indicated below in order to get my function reliable.

Now still having issues after much code optimisation, even though metrics look rock solid.

因此，我正在对一些Azure Durable Functions进行原型设计，以尝试了解它们是否适合我们内部 API 系统的建议解决方案。

基于示例，我创建了一个Orchestrator 客户端( HelloOrchestratorClient.cs)，它响应HttpTrigger. 此客户端从原始请求中提取一些信息，然后继续触发Orchestrator 函数( HelloOrchestrator.cs)，传入一些提取的信息：

复杂的 HelloOrchestratorClient.cs：

现在HelloOrchestrator.cs只是调用我们的一个内部 API 并返回一个JsonProduct有效负载（简单的 POCO 描述，你猜对了，一个标题），使用ActivityTigger命名HelloOrchestrator.APICall来调用 API。

复杂的 HelloOrchestrator.cs：

旁注：如果我可以让它工作，计划是将一堆进程扇出到不同的 API 并再次扇入并合并 JSON 有效负载并将其返回给发起者。

我遇到的问题

因此，当我List<JsonProduct>从 中返回时HelloOrchestrator.Run，我会收到NullReferenceException在此Gist（大堆栈跟踪）上找到的以下内容，并且我收到来自Orchestrator Client的500 响应。

下面证明output返回的确实在运行时有一个对象：

可能是由于（再次在这里JsonProduct找到模型类）的复杂性吗？我问，因为当我将我的Orchestrator 函数换成更简单的模型结构时，我没有收到 500，而是收到了我的 JSON 有效负载。

此示例显示了Simple Orchestrator 函数 HelloOrchestrator.cs，返回一个简单的TestToDo.cs（模型的要点）平面对象，该对象不会出错：

简单的 HelloOrchestrator.cs：

更多信息

如果你需要我的完整原型项目，你可以在这里找到它们：

• 复杂项目（抛出 500 和异常）

当你运行它时，在 Postman 之类的东西中使用以下内容（在 F5 之后）：

http://localhost:7071/api/orchestrators/E1_JsonProduct/wait?timeout=20&retryInterval=0.25&api=products&apiVersion=v1&filterByImprints=W%26N&N

• 简单项目（无 500 或抛出异常）

当你运行它时，在 Postman 之类的东西中使用以下内容（在 F5 之后）：

http://localhost:7071/api/orchestrators/E1_Todo/wait?timeout=20&retryInterval=0.25