问题标签 [retrypolicy]

我使用 nuget 包 "Microsoft.Azure.Storage.Queue" Version="11.1.7" 创建 Azure 存储队列客户端，如下所示，

在通过上面的“qClient”实例将消息发布到队列时，希望结合重试机制来克服任何瞬态故障。

如何在上述创建延迟队列连接的方式中加入重试机制？

我正在使用 ApacheHttpClient和Failsafe java 库。下面是（伪）代码的样子：

它正在调用一个测试端点，localhost我已经模拟了它来执行以下操作：

• 前 3 个请求返回 404
• 第 4 个请求返回 200

现在，当我执行上面的代码时，我看到了以下行为：

1. HttpClient发送get请求，结果为404
2. 作为响应404，重试策略启动并重试请求
3. 重试请求失败，400 没有实际到达代理
4. 所有随后的重试都失败了400。响应没有任何正文

我希望第 2 步中的请求能够命中我的模拟，但是，它没有命中就失败了。是否HttpClient缓存响应或尝试阻止后续重试？

SqlAzureExecutionStrategy 不能与用户发起的事务一起使用。只要您在事务中执行代码，它就会引发异常。MS解决方案是更改代码

但这不是一个选项，因为我有很多遗留代码，我无法更改这么多代码，并且事务范围内的代码可能无法执行两次。

所以我的解决方案是在没有事务时使用 SqlAzureExecutionStrategy，如果代码在事务中，则使用 DefaultExecutionStrategy（至少我在代码的某些部分进行了重试）

我已经进行了一些快速测试，并且可以正常工作...但是我会遇到问题吗？这是个好主意还是坏主意？

谢谢！

我有一个发布大量事件的事件网格，以及一个需要使用其中一些事件的逻辑应用程序。不能保证这些事件是有序的，需要先处理另一个事件的事件可能会过早地出现在逻辑应用程序中，从而导致它们失败。
从文档中，我可以看到事件网格支持重试策略，时间间隔越来越长。这将解决我的问题。
但是，似乎有问题的逻辑应用程序总是从事件网格中确认事件，即使该进程提前停止，Terminate 操作处于失败状态并带有错误代码。
从逻辑应用概述中，运行显示为失败。但是事件网格从不尝试重试，并且似乎认为事件是成功的。如何使事件网格重试失败的逻辑应用运行？

我正在使用 AWS CDK 创建一个状态机。而不是默认的重试策略，如下所示：

我只想拥有一个看起来像这样的包罗万象的政策：

不幸的是，我在部署堆栈时找不到删除默认策略的方法。我的包罗万象只是被添加到重试策略数组的末尾。

任何人都知道如何摆脱默认策略？

自从最新的 Microsoft.Azure.WebJobs 程序集发布以来，现在可以通过属性设置 Azure 函数的重试策略，例如[FixedDelayRetry]. 我对这个功能很感兴趣，因为我有一个 Blob 触发功能，失败时默认重试五次，我对重试策略功能不感兴趣。我希望该功能在失败时不重试，或者只重试一次。

所以我已经在我的函数中设置了这个属性，如下所示，如果函数失败，我已经指出了最大重试次数：

当我在我的测试环境中使用存储模拟器和我的 CosmosDb 模拟器尝试此代码时，它工作得非常好，该函数在遇到异常时只重试一次。

但是，当我在 Azure 平台上运行我的函数时，它不会在失败时仅重试一次，而是重试......九次。我将重试次数的最大值设置为 5，这一次，函数重试了 25 次。我的感觉是，该函数不是重试属性中指定的次数，而是将该数字乘以默认重试策略 5。您可以在下面看到我的日志，其中该函数清楚地重试了 10 次：

我究竟做错了什么 ？

我在Python中使用grpc，发现两个节点之间的通信不小心遇到了StatusCode.UNAVAILABLE。

我找到了一个解决方案，它说 UNAVAILABLE 是一个可重试的错误，我们应该重试：https ://github.com/grpc/grpc/issues/16515 。

所以我查阅了文档，发现了这个：https ://github.com/grpc/proposal/blob/master/A6-client-retries.md 。本文档显示了一个配置演示，如下所示。

我尝试按照这个问题中的两个示例进行操作，但它仍然不起作用：Use retryPolicy with python GRPC client

这是我的代码，这里还有另一个问题。我不太明白“。”的意思。：

我想知道的是Python GRPC是否支持“重试”，它的正确用法是什么。

寻找有关使用 SQS 优化 lambda 重试策略的输入。目前，我有一个由 S3 PUT 操作调用的 Lambda 函数，该函数发布到第三方网络钩子，我正在尝试解决来自所述网络钩子的可能错误/500。我设置了两个 SQS 队列用作重试策略，如下所示：

但是，在重新评估该策略后，我意识到我有两个 lambda 函数在做完全相同的事情（由 S3 PUT 触发的 lambda 和“重新处理”的 lambda，两者都只是点击了 webhook）。我的第二个想法是这样的：

这将消除对执行完全相同的事情的额外 lambda 的需要。是否有任何我没有考虑的可扩展性/成本问题？我能想到的拥有两个 lambda 的唯一好处是并发限制加倍，因为重试将由单独的函数处理。作为参考，这个过程的日吞吐量应该是每天 10-15k 次调用，偏高。

我有使用 .NET Core 3.1\C# 的 Azure Function 我正在尝试使用重试策略。 请参阅下面的函数代码：

当函数失败时，重试逻辑在第一次、第二次和第三次重试时正常工作，但对于最后两个第四次和第五次，它会同时触发它们。请参阅下面的日志：

不管设置了多少次重试或时间间隔，它总是同时触发最后两次重试。

问题：如何解决最后两次重试同时触发的问题？

我只是熟悉 Polly，我正在尝试从一个简单的重试机制开始。

这是代码：

我希望NotImplementedExceptionPolly 捕获并重试，直到返回所需的结果。但起初异常引发程序停止！我在哪里做错了？提前致谢