问题标签 [transient-failure]

我有几十个 SQL Server 作业，作业活动监视器显示这些作业似乎尚未执行。

我所做的所有研究都没有为我提供任何关于为什么这些工作无法执行的线索。所有这些工作的描述都是一样的：

我期待看到这些作业成功执行并完成。

语境

我正在开发一个 REST API，正如您所料，它由多个外部跨网络服务、API 和数据库支持。很可能在任何时候都会遇到暂时性故障，并且应该重试该操作。我的问题是，在重试操作期间，我的 API 应该如何响应客户端？

假设客户端正在发布资源，而我的服务器在尝试写入数据库时​​遇到了暂时性异常。使用重试模式可能与断路器模式的组合，我的服务器端代码应该尝试重试操作，遵循随机线性/指数回退实现。客户显然会在那段时间等待，这不是我们想要的。

问题

客户端在哪里适合重试操作？

1. 我是否应该isTransient: true在 JSON 响应中提供一个指示符并让客户端重试？
2. 我是否应该将重试留给服务器并以指示服务器正在主动重试请求的消息和状态代码进行响应，然后让客户端轮询更新？在这种情况下，您将如何确定轮询间隔而不会使服务器过载？或者，服务器是否应该通过 Web 套接字进行响应，以便客户端不需要轮询？
3. 如果在重试操作期间出现意外的服务器崩溃，会发生什么？显然，当服务器恢复时，它不会“记住”它正在重试操作的事实，除非该事实在某个地方持续存在。我想这是一个非关键问题，如果我试图解决它只会导致进一步不必要的复杂性。

我可能过度思考了这个问题，但是虽然有很多关于实现瞬态异常重试逻辑的文档，但我很少遇到讨论如何在这段时间内让客户端“挂起”的资源。

注意：我意识到已经提出了类似的问题，但我的查询更具体，因为我对客户端适合给定重试操作的不同选项特别感兴趣，客户端在这些情况下应该如何反应，以及什么如果发生中断重试序列的崩溃，就会发生这种情况。

非常感谢。

我在 Perl v5.16 中遇到来自 File::NFSLock 的奇怪行为。我使用过时的锁定超时选项为 5 分钟。假设我有三个进程。其中一个在释放锁之前花费了 5 分钟以上，并且进程 2 获得了锁。然而，即使进程 2 的锁定时间不到 5 分钟，第三个进程即将到来并删除锁定文件，导致第二个进程在删除自身持有的 NFSLock 时失败。

我的理论说进程 3 错误地读取了锁的最后修改时间，因为它是由进程 1 而不是进程 2 写入的。我正在对挂载在 NFS 上的分区写入 nfs 锁。

有人对 perl NFSLock 有想法或面临类似问题吗？请参考以下快照

如果我在进程 1 的调试器点阻塞超过 5 分钟，我正在观察这种行为

Linux 内核是否包含一些机制来检测 SMP 实现中某些 CPU 的故障？例如，如果多核平台上的某些内核在禁用中断后由于无限循环而卡住或阻塞，或者如果某些内核由于某些硬件故障（过热等）而断电，其余的会系统会注意到这一点并对此做出反应吗？

我有一些存储过程Cosmos DB，我想将其转换为 .NET 事务。最近，我看到这篇文章https://devblogs.microsoft.com/cosmosdb/introducing-transactionalbatch-in-the-net-sdk/讨论了事务支持。我也能够测试它，它似乎工作正常。

我知道 .NET 已在其许多支持的包中添加了内置的重试逻辑。是否TransactionalBatch有任何内置的重试策略？重试任何失败的推荐方法是什么？上面的帖子正在看IsSuccessStatusCode。一旦状态为失败，我们是否应该重试？

鉴于此代码尝试调用AuthenticationManager.Authenticate()10 次，然后在 10 次CustomException尝试失败后抛出：

为什么CustomException没有从后备动作中抛出？正确的方法应该是什么？

Angular 的 HTTPClient 或任何等效的 Angular 是否能够检索用于进行 REST 数据检索调用的 TCP 连接的 source_address？

参考 https://groups.google.com/g/google-chrome-developer-tools/c/OBQKVhaGE-s

在此，我们想在程序中捕获 source_address = "10.1.2.116:62158" 和 address_list = ["10.1.1.218:48443"] 以便我们记录以供审核。

大多数情况下，我们正在尝试捕获源地址和目标地址（包括端口号）的流关闭失败，并对其进行改进。

谢谢， Saravanan Thangavel

我在 .Net 核心 EF 应用程序中使用 EnableRetryOnFailure 并根据https://www.npgsql.org/efcore/misc/other.html添加了逻辑。我希望能够判断这些事件何时/是否发生，以确认它正在工作，而不仅仅是没有任何瞬时连接错误。

在此先感谢您的任何指点。鲁文

我的 IT 人员刚刚将我们的 MySQL 数据库更新到了一个新的集群，现在我收到了类似以下的暂时错误：

引发了一个异常，可能是由于暂时性故障。考虑通过将“EnableRetryOnFailure()”添加到“UseMySql”调用来启用瞬时错误恢复能力。

因此，经过研究，我添加了以下代码：

然后，不幸的是导致了一个新错误：

错误 CS1061“MySQLDbContextOptionsBuilder”不包含“EnableRetryOnFailure”的定义并且没有可访问的扩展方法“EnableRetryOnFailure”

我不知道我是否缺少参考，但智能感知无济于事

所以，我做更多的研究并在这里找到信息https://dev.mysql.com/doc/connector-net/en/connector-net-entityframework60.html和这里https://entityframeworkcore.com/knowledge-base/57595183 /using-entity-framework-with-multiple-databases-and-providers-in-the-same-project--sql-server-and-mysql-关于使用 MySQL 中的这一行：

这也会引发错误。

有谁知道我如何使用 MySQL 实现连接弹性/重试逻辑？

.Net 5、MySQL 5.7、MySqlConnector 8.0.20

I'm using the RabbitMQ.Client nuget package to publish messages to rabbitmq from a .NET core 3.1 application. We are using the 5.1.0 version of the library.

We want to improve the resiliency of our application, so we are exploring the possibility to define a retry policy to be used when we send messages via the IModel.BasicPublish method. We are going to employ the Polly nuget package to define the retry policy.

Thw whole point of retry policies is retrying a failed operation when a failure deemed to be transient occurs. What I'm trying to understand is how to identify a transient error in this context.

Based on my understanding, all the exceptions thrown by the RabbitMQ.Client derives from the RabbitMQClientException custom exception. The point is that there are several exception types defined by the library which derives from RabbitMQClientException, see here for the full list.

I didn't find any specific documentation on that, but by reading the code on github it seems that the only custom exception thrown by the library when a message is published is AlreadyClosedException, this happens when the connection used to publish the message is actually closed. I don't think that retrying in this case makes sense: the connection is already closed, so there is no way to overcome the error by simply retrying the operation.

So my question is: what exception types should I handle in my Polly retry policy which I want to use to execute the IModel.BasicPublish call ? Put another way, which are the exception types representing transient errors thrown by IModel.BasicPublish?