问题标签 [retry-logic]

我刚刚开始使用 Ruby，但我所遵循的手册似乎已经过时了。我一直在做一些研究，但我一直无法找到明确的答案。

该手册在应该充当循环的方法中使用了“重试”关键字，但它在没有开始/救援块的情况下使用，当您强制“重试”关键字位于开始时，行为似乎完全不同/救援块。

我尝试了很多事情： - 第一个是在方法开始时使用“begin”关键字，在重试点使用“raise”，然后是相应的“rescue”；重试; 结尾;'。-最后一个是在外面使用'begin/rescue'块，包装方法的调用。

按照手册中的逻辑，只有最后一个可以正常工作。

有一些例子：

手册中的代码如下：

结果：012

我尝试了以下方法：

结果： 无限数

结果：012 （加上一个明显的无限循环打印什么）

我希望你能把我从这个存在的怀疑中解脱出来，但这是我的结论。

在强制使用“重试”关键字的开始/救援块之前，它可以以一种不能再使用的方式使用，重复调用一个方法，尽管它位于该方法的内部。

现在，它只是跳转到“开始”语句。

但我不确定这一点，我需要确认。如果是这样，是否有任何形式可以恢复这种使用？

谢谢。

我有一个看起来像这样的高级代码结构：

问题是这段代码可能会失败，即.get取决于None时间，例如我经常抓取谷歌页面，然后我会等待并重试......

我可以像这样等待，即在 11-16 秒之间随机等待：

什么是优雅的单线方式来[等待]循环，直到执行结果block不为空？就像是：

我正在使用Failsafe（https://github.com/jhalterman/failsafe）作为我的重试逻辑框架，并想了解更多关于故障安全的“运行”方法的工作原理。

假设我有：

那么当MyCurrentFunction运行时，会Failsafe.run阻止 MyCurrentFunction 的执行吗？换句话说，会OtherFunction1在所有重试完成之前执行吗？

我正在阅读RW book。

计时器没有使用period变量，因此它会触发一次并且不会重复。那它为什么要这么做take(1)。在本书的过程中，我多次看到这种情况发生。

我对空手道很陌生。我正在尝试使用重试逻辑。我在下面发布了我尝试过的代码。对此的任何帮助表示赞赏。提前致谢 。

第1步：我想检查响应actualNo == expectedNo

Step2：如果actualNo不等于expectedNo，脚本必须调用CallWait.feature，等待30秒，然后检查响应是否有期望值。

Step3：如果 actualNo == expectedNo ，则打印成功消息并退出重试，否则退出重试并显示失败消息

代码：然后重试直到 (response.actualNo==expectedNo) || karate.call('classpath:com/sample/test/setup/CallWait.feature') {waitDuration: #(waitTime)}

有谁知道在 .NET CORE 中是否有可能拥有服务器中间件，该中间件会根据原始请求的响应重复请求。

是否可以在传出响应中发送另一个请求？

[更新说明] - 场景是客户端发出请求，.NET Core Web API 尝试执行请求，返回错误，服务器中间件检测到错误并再次发送请求。

我可以在 Web API 控制器中执行此操作，但必须在每个控制器方法中重复此操作。我也试图避免使用基本控制器。

谢谢

我在java中使用grpc-streaming。我有一个持久的开放流，客户端和服务器同时通信。当我调用onNext发送消息时，grpc 会在内部缓冲消息，并将其通过网络异步发送。现在，如果流在发送数据的过程中丢失，onError则调用。我想知道正确的做法是什么：

1. 找出哪些消息已成功发送
2. 如何重试未发送的消息

目前，我正在考虑在应用层实现一个“ack”机制，对于每收到 x 个项目，接收者会发回一个 ack 消息。然后为了实现重试，我需要在发送方缓冲项目，并且只有在收到 ack 时才将它们从缓冲区中删除。此外，在接收方，我需要实现一种机制来忽略收到的重复项目。

示例： 假设我们每发送 100 个项目就发送一个 ack。我们在第 3 批 (200-300) 上收到 ack，然后在发送项目 300-400 时收到错误。我们再次尝试发送项目 300-400 但客户端已成功收到 300-330 并且它将再次接收它们。因此，客户端需要忽略前 30 项。

可以在应用层实现这一点。但是，我想知道是否有更好的实践/框架可以解决这个问题。

我有一个递归异步函数getResponse(url,attempts = 0)，它轮询外部 api 以获取响应，并在达到 X 次重试或服务器错误后解决或退出。但是，它的内部“时钟”基于重试次数（在允许延迟以避免速率限制之后），但我也希望灵活地设置基于时间的计时器，这将解决函数并结束递归。理想情况下，我希望能够将基于时间的计时器包装在我的递归异步函数周围，就像这样timed(getResponse(url),3400)

我只设法让基于时间的计时器和基于“重试”的计时器一起工作，方法是将两个计时器打包在一个异步函数中，并将局部变量expired用作退出标志并在两个函数上设置 Promise.race 条件。

我觉得这不是正确的方法，并且希望对timed(getResponse(url),3400)解决方案有任何帮助。

由于旧版独立 App Engine SDK (appcfg) 将于 2019 年 7 月 30 日弃用，因此有必要从 cron.xml 迁移到 cron.yaml。

当我第一次运行 mvn package appengine:deploy 将我的应用程序部署到谷歌应用引擎时，它失败并出现以下错误：- Unable to find property 'retry_parameters' on class: com.google.apphosting.utils.config.CronXml$Entry

我的 cron.yaml 如下：

我发现当我使用下面出现在cron.yaml 参考中的示例 cron.yaml 时，甚至会出现同样的问题

达到最大重试次数时如何抛出异常。在我的情况下，当Response有其他代码而不是 200 时，我想抛出异常。