最初，我想将此博客称为“ 具有拦截器驱动的重试策略的灵活超时 ”，但后来我认为它太“繁重”。 该声明以及修改后的标题应该（希望）使您了解此帖子可能谈论的内容;-)

触发

这篇文章主要由我在较早的一篇文章中收到的评论/问题之一驱动，其中简短地讨论了超时机制以及如何使用它们为状态和Singleton EJB定义“并发策略”。

问题

虽然超时是在EJB容器中强制执行并发策略和控制资源分配/使用的好方法，但是当超时不一致且不可预测时，就会出现问题。 那么您如何配置超时策略呢？

当然，没有完美的解决方案。 但是，我想到的一项工作是“ 重试 ”失败的方法（这对于您的给定方案可能不适当或不可能，但如果用例允许，则可以应用）。 这是“ 跨领域 ”关注（换言之，“ 方面 ”）的一个很好的例子。 Java EE为此的答案是– Interceptors 。 这些要比默认的“ 带有try-catch块的 “ rinp-repeat-until-xyz ”更好，因为

• 代码重用
• 灵活性

要点（解决方案）

这是高级描述（ 代码可在Github上获得 ）

• 定义一个简单的注释，表示“重试策略元数据”，例如重试次数

• 定义具有实现的重试器以重试目标方法–这将使用上述“重试策略”元数据并相应地执行操作

• 将此拦截器附加到所需的方法（调用方）

• （可选）使用@InterceptorBinding

样例代码

• 使用Singleton EJB模拟示例服务，并通过显而易见的Thread.sleep（）引入延迟（当然，这在Java EE容器中是禁止的）
• 使用JAX-RS资源，该资源注入并调用Singleton EJB，并且是根据“策略”进行“重试”的候选对象
• 可以通过在任何兼容Java EE（6或7）的服务器上部署并使用Apache JMeter模拟并发客户端/请求进行测试（在http：// serverip：port / FlexiTimeouts / test上调用HTTP GET）

没有重试（拦截器）配置，测试（针对并发请求）将导致HTTP超时（408）。

一旦重试拦截器被激活，就会有一些延迟，因为一旦失败，任务将自动重试。 当然，这将取决于（并发请求的）数量，并且需要相应地调整阈值–对于高度并发的环境，阈值较高（通常，不理想）

其他想法

• 在代码中定义阈值或重试策略不是强制性的。 也可以将其外部化（以使事情更灵活），例如，使用@RetryPolicy指向包含所需策略元数据的文件
• 重试阈值不是唯一可配置的属性。 您可以具有其他条件，并在拦截器逻辑中使用它
• 可以公开与成功/失败/重试有关的统计信息。 最好以异步方式执行此操作（通过@Async EJB将其推送到JMX？），这样就不会妨碍Interceptor自身的性能。

干杯!

翻译自: https://www.javacodegeeks.com/2015/11/implementing-auto-retry-in-java-ee-applications.html