问题标签 [retrypolicy]

我在我的 android 项目中使用 volley 库与服务器交互。但是，当互联网连接速度很慢并且已经发出请求时，volley 会再次重试请求。虽然，我已经将 defaultRetryPolicy 设置为：

它似乎对我不起作用。

请提出一些建议。

我有一个使用 Spring Batch 3.0.6 的应用程序。Spring Batch 作业使用块处理。提交间隔设置为 100，重试限制设置为 5。

当达到提交间隔时，写入器将数据块（100 条记录）写入另一个应用程序（通过 TCP）。如果其中一条记录是错误的（无论出于何种原因导致异常），那么 Spring Batch 会尝试写入该块 5 次（重试限制）并且每次都失败（如预期的那样）。

Spring Batch 然后尝试通过一次重试一条记录来找出块中的 100 条记录中的哪一条失败（即提交间隔 = 1）。这似乎是重试的默认行为。

有没有办法通过一次重试 10 条记录并逐渐缩小重试大小直到找到有问题的记录来提高效率。这样，如果第 95 条记录是坏的，那么我们发现它比从记录 1 开始一次检查它们更快。

我从 2011 年发现了这篇文章：

Spring Batch：在写入期间回滚后不遵守提交间隔

有没有办法让 SB 首先尝试更小的块来缩小坏记录的位置。较小的块大小（例如，10 个项目）可以是可选的用户可配置项目，之后 SB 可以一次尝试一个项目来查找不良记录。

这是我的骡流程 1：

第一个流程有一个error handling：

File（为每条处理的消息写一个文件）

流程 2：

恢复流程（使用groovy 脚本调用）：

这是来自 Mule 的 XML：

1. 我停止服务ActiveMQ，它存储了一个包含错误处理消息的文件，我收到了典型的错误：

无法处理事件，因为“Active_MQ”已停止

2. 然后，我ActiveMQ service再次运行并使用 groovy 脚本启动恢复流程。该流恢复所有消息，转换为字符串并返回到第一个流以重新排队。

问题是mule没有检测到服务何时再次运行，我需要重新启动mule项目才能检测到它。

有没有办法自动检测activeMQ何时再次与Mule一起运行？

我的服务是 DService，我是服务链中的第四个环节，即调用流程是 Online User -> AService -> BService -> CService -> DService -> EService。

当我从 DService 调用 EService 时，它​​会抛出像 HttpTimeoutException 这样的可重试异常。我通常重试 2-3 次，如果即使在 2-3 次重试后仍然失败，我也会抛出异常。

我的问题是，我向 CService 抛出的异常应该是可重试的还是不可重试的？请在下面找到我对这两种选择的优缺点的评估

从 DService 抛出可重试异常的缺点 - 如果 DService 抛出可重试异常，按照相同的约定，CService 也可能重试 DService 2-3 次，并且在每次 CD 调用中，D 将再次尝试 2-3 次 E 服务调用。同样，随着我们在调用链上的上升，最终对 EService 的调用将成倍增加。因此，如果 EService 网络确实长时间停机，我们正在谈论大量不必要的呼叫。这可以通过为链中的每个调用设置超时来缓解，但仍然不确定这是否足以缓解不必要的调用次数。

从 DService 抛出可重试异常的优点 - CService 将在某个时间后重试，因为在随后的重试中我们可能会得到正确的值（在时间限制内） - 特别是如果客户端是一些后端作业，那么他们可以在放弃之前以指数方式重试很长时间. 抛出 Un-Retriable 异常会清除此选项

请就此提出您的看法和建议

谢谢， 哈里什

使用 AOP 的 RetryLogic 不适用于 MongoItemWritrer ，但同样适用于我的自定义 Readers 和 writers 我在这里做错了什么。

下面是代码片段。

没有找到与我的问题相关的任何帖子。任何帮助，将不胜感激。

此处的逻辑应用文档表明逻辑应用支持对 http 操作使用以下内容的重试策略"input"

该文档指出：

重试间隔以 ISO 8601 格式指定。它的默认值为 20 秒，这也是最小值。最大值为 1 小时。默认重试次数为 4，4 也是最大重试次数。如果未指定重试策略定义，则使用带有默认重试计数和间隔值的固定策略。要禁用重试策略，请将其类型设置为无。

它没有明确指出是否None以及Fixed是否是唯一的重试策略类型。

我想知道是否有一种ExponentialBackoff类型（或类似的东西）。我还想知道它是否支持定义随机增量来帮助避免重试。

谢谢！

我试图从一个空的 blob 容器中下载一个文件，我得到了 404 的预期。问题是我在 fiddler 中只看到 1 次调用此文件，而不是 3 次（正如我在 RetryPolicy 中指定的那样），而且我注意到调用在 1 秒内完成，所以它肯定没有等待 10 秒再试一次。 .. 我怎么知道 BlobClient 是否真的重试了？

var blobClient = this.storageAccount.CreateCloudBlobClient(); blobClient.DefaultRequestOptions.RetryPolicy = new LinearRetry(TimeSpan.FromSeconds(10), 3); var anchorString = await cloudBlobContainer.GetBlockBlobReference(ARGO_ANCHOR_VERSION_FILE).DownloadTextAsync();

我们正在使用 Azure 表存储，并且在执行 InsertOrMerge 操作时偶尔会出现 408 超时。在这种情况下，我们想重试，但似乎没有针对这些错误遵循重试策略。

这是我们用来处理表格交互的一个类。GetFooEntityAsync 方法尝试从表存储中检索实体。如果不能，它会创建一个新的 FooEntity 并将其添加到表中（映射到 FooTableEntity）。

调用 GetFooEntityAsync() 时，偶尔会执行“请求失败”行。检查值时args.RequestInformation.HttpStatusCode= 408。但是：

• Debug.WriteLine("Got a 408");在 GetFooEntity 方法中永远不会执行。

• Debug.WriteLine($"Retry policy activated...在DefaultOperationContext.Retrying委托中永远不会执行（我希望这会执行两次 - 这不是重试吗？）。

• DefaultOperationContext.RequestResults包含一长串结果（大多数状态码为 404，有些为 204）。

根据这篇（相当旧的）博客文章，代码在 400 和 500 之间以及 501 和 505 之间的异常是不可重试的。然而，超时（408）正是我们想要重试的情况。也许我需要为这种情况编写自定义重试策略。

我不完全理解 408 的来源，因为除了调用 RequestCompleted 委托时我无法在代码中找到它。我一直在为我的重试策略尝试不同的设置，但没有运气。我在这里想念什么？如何从表存储中获得重试 408 的操作？

编辑：我已更新代码以显示我实施的自定义重试策略，以重试 408 错误。但是，似乎我的重试断点仍未被命中，因此似乎未触发重试。我的重试策略未激活的原因可能是什么？

我使用Curator到newClient，并设置重试策略，但如果连接字符串错误，重试连接将一直运行直到内存不足，但我希望程序退出一次重试3次。

当我们有一段代码经常失败并且必须重试时。然后我们使用重试模式。

在重试该请求之前，我们通常会延迟几毫秒。我想知道为什么我们需要一些延迟？如果重试请求没有等待并再次发送请求会发生什么。