问题标签 [spring-retry]

我正在使用 spring 重试模板，当有重试过程正在运行时，我无法停止服务器。如果我试图停止服务器，它是说 tc 服务器没有响应，你想终止服务器吗？

我遵循以下方式，但不幸的是结果相同。

如何在 Web 应用程序中的所有其他 bean 被销毁之前关闭 Spring 任务执行器/调度器池？

提前致谢

我必须处理一个不能为 Spring 使用 Java-Config 的项目，但我必须使用 XML-Config。现在我正在寻找与 Java-Config 中的 @EnableRetry 等效的 XML-Config。

我想让这条线工作。

我们计划使用 spring 重试功能，并希望在布尔标志而不是异常上重试。当我们使用 时SimpleRetryPolicy，重试似乎只发生在异常上。我们可以调整它或使用不同的重试策略来检查布尔标志吗？

谢谢

我正在使用int:request-handler-advice-chain我的服务激活器。它可以正常工作，org.springframework.retry.policy.SimpleRetryPolicy但是我想org.springframework.retry.policy.ExceptionClassifierRetryPolicy根据服务激活器抛出的异常允许不同次数的重试。

我遇到的问题是，当异常到达时，ExceptionClassifierRetryPolicy它是

org.springframework.integration.MessageHandlingException

MessageHandlingException任何人都可以建议从提供给的原因（即我的例外）的最佳方法ExceptionClassifierRetryPolicy？

解决方案感谢 Artem 的以下建议：

创建一个 SubclassClassifier 的子类，在 MessagingException 的情况下返回原因

然后是一个新的 ExceptionClassifierRetryPolicy 子类，它使用新的分类器和 policyMap

目前这不支持在 MessagingException 上重新绑定，但这对我们的用例来说很好。否则完美运行。

I am using Spring-Retry for some database operations. On a SQLRecoverableException I retry three times (this assumes that whatever is causing the exception is non-transient if it fails three times), on a SQLTransientException I retry indefinitely (the program can't do anything without access to the database, so it may as well keep retrying until the user decides to reboot the server), and on any other exception I don't retry. I use an exponential backoff policy with a base retry of 100ms and a max retry of 30,000ms.

Ideally, I would like to use a fixed backoff of 100ms for all SQLRecoverableExceptions, and only apply the exponential backoff policy to SQLTransientExceptions. I could accomplish this with nested retries, but that will greatly increase the code complexity - given no other option I would prefer to simply apply the exponential backoff to both SQLRecoverableException and SQLTransientException exceptions.

Is there a way for me to apply different backoff policies to different exceptions using a single retry template?

我正在寻找一种使用 spring amqp 和 Rabbit MQ 使用退避策略实现重试的好方法，但要求是不应阻塞侦听器（因此可以自由处理其他消息）。我在这里看到了一个类似的问题，但它不包括“退出”的解决方案：

RabbitMQ 和 Spring amqp 重试而不阻塞消费者

我的问题是：

1. 重试时默认的 spring-retry 实现会阻塞线程吗？github中的实现表明确实如此。

2. 如果上述假设成立，那么实现此目的的唯一方法是实现一个单独的重试队列（DLQ？），并为每条消息设置一个 TTL（假设我们不想在退避间隔内阻塞线程）。

3. 如果我们采用上述方法（DLQ 或单独的队列），每次重试尝试不需要单独的队列吗？如果我们只使用 1 个队列进行重试，同一个队列将包含 TTL 从最小重试间隔到最大重试间隔的消息，如果队列前面的消息具有最大 TTL，则它后面的消息不会即使它有最小 TTL 也被捡起。这是这里的 Rabbit MQ TTL 文档（请参阅注意事项）：

4. 是否有另一种方法来实现非阻塞退避重试机制？

添加一些配置信息以帮助解决@garyrusel：

队列配置：

是否可以为rabbitmq连接设置重试尝试？如果可能的话怎么做？

我目前正在从我的应用程序连接到 AMQP (RabbitMQ)，如果 rabbitmq 关闭，则抛出 AmqpConnectionException 并重试 10 次以再次建立连接。

如何将此重试尝试减少到​​ 3 次然后退出。

我正在使用 CachingConnectionFactory 连接到 rabbitmq 服务器。

I am trying configure spring amqp to only retry a message a defined amount of times. Currently a message that fails e.g. because of a DataIntegrityViolationException is redelivered indefinitely.

According to the documentation here I came up with the following configuration

This does not seem to be applied - the messages are still tried indefinitely.

Feels like I am missing something here.

Here is my remaining configuration regarding AMQP:

I am using spring-amqp 1.5.1.RELEASE.

Any help is appreciated.

对于重试功能，我想使用 org.springframework.batch.retry.interceptor.RetryOperationsInterceptor.

我可以在 spring-batch 2.1.X 中找到它，但在 spring-batch 2.2.X 中找不到。

被删除了吗？它有问题吗？

如果它被删除并且我应该使用不同的方法，那是什么？

如果我在我的块中定义了一个跳过限制，那么一个重试模板是通过创建的FaultTolerantStepBuilder。其实我不想用这个RetryTemplate。

如果ItemWriter org.springframework.retry.support.RetryTemplate#handleRetryExhausted我再次调用我的 ItemWriter 失败并且没有解决方案来阻止第二次调用。设置重试策略对此调用没有影响。

请你帮助我好吗？我找不到阻止此重试的正确方法。

}