最初，我想將此博客稱為“ 具有攔截器驅動的重試策略的靈活超時 ”，但后來我認為它太“繁重”。 該聲明以及修改后的標題應該（希望）使您了解此帖子可能談論的內容;-)

觸發

這篇文章主要由我在較早的一篇文章中收到的評論/問題之一驅動，其中簡短地討論了超時機制以及如何使用它們為狀態和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

總結

以上是生活随笔為你收集整理的在Java EE应用程序中实现自动重试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。