spring-retry-toolkit

यह प्रोजेक्ट Spring एप्लिकेशन के लिए डिक्लेरेटिव रिट्राई सपोर्ट प्रदान करता है। इसका उपयोग Spring Batch, Spring Integration और अन्य में किया जाता है। स्पष्ट उपयोग के लिए इम्पेरेटिव रिट्राई भी समर्थित है।

संस्करण

यह संस्करण java8 और spring4 या spring5 के लिए spring-retry को 2.0.13 के साथ ठीक करता है, अधिक जानकारी के लिए, कृपया आधिकारिक Spring 2.0.13 संस्करण देखें

त्वरित शुरुआत

यह अनुभाग Spring Retry के साथ शुरुआत करने का एक संक्षिप्त परिचय प्रदान करता है। इसमें एक डिक्लेरेटिव उदाहरण और एक इम्पेरेटिव उदाहरण शामिल है।

डिक्लेरेटिव उदाहरण

निम्नलिखित उदाहरण दिखाता है कि Spring Retry का उपयोग उसकी डिक्लेरेटिव शैली में कैसे करें:

@Configuration
@EnableRetry
public class Application {

    @Bean
    public Service service() {
        return new Service();
    }

}

@Service
class Service {
    @Retryable(RemoteAccessException.class)
    public void service() {
        // ... do something
    }
    @Recover
    public void recover(RemoteAccessException e) {
       // ... panic
    }
}

यह उदाहरण service मेथड को कॉल करता है और, यदि यह RemoteAccessException के साथ विफल हो जाता है, तो पुनः प्रयास करता है (डिफ़ॉल्ट रूप से, तीन बार तक), और फिर यदि असफल रहता है तो recover मेथड को आज़माता है। @Retryable एनोटेशन विशेषताओं में अपवाद प्रकारों को शामिल और बहिष्कृत करने, पुनः प्रयासों की संख्या सीमित करने, और बैकऑफ़ के लिए नीति निर्धारित करने के लिए विभिन्न विकल्प हैं।

पहले दिखाए गए @Retryable एनोटेशन का उपयोग करके रिट्राई हैंडलिंग लागू करने के डिक्लेरेटिव दृष्टिकोण की AOP क्लासेस पर एक अतिरिक्त रनटाइम निर्भरता है। अपने प्रोजेक्ट में इस निर्भरता को हल करने के तरीके के विवरण के लिए, 'Java Configuration for Retry Proxies' अनुभाग देखें।

इम्पेरेटिव उदाहरण

निम्नलिखित उदाहरण दिखाता है कि Spring Retry को इसकी इम्पेरेटिव शैली में कैसे उपयोग करें (संस्करण 1.3 से उपलब्ध):

RetryTemplate template = RetryTemplate.builder()
				.maxAttempts(3)
				.fixedBackoff(1000)
				.retryOn(RemoteAccessException.class)
				.build();

template.execute(ctx -> {
    // ... do something
});

1.3 से पहले के संस्करणों के लिए, RetryTemplate अनुभाग में दिए गए उदाहरण देखें।

निर्माण

Spring Retry के लिए Java 1.7 और Maven 3.0.5 (या उससे अधिक) आवश्यक है। निर्माण के लिए, निम्नलिखित Maven कमांड चलाएँ:

$ mvn install

विशेषताएँ और API

यह अनुभाग Spring Retry की विशेषताओं पर चर्चा करता है और दिखाता है कि इसके API का उपयोग कैसे करें।

RetryTemplate का उपयोग करना

प्रोसेसिंग को अधिक मज़बूत और विफलता के प्रति कम प्रवण बनाने के लिए, कभी-कभी किसी विफल ऑपरेशन को स्वचालित रूप से पुनः प्रयास करना सहायक होता है, ताकि वह किसी बाद के प्रयास में सफल हो सके। इस प्रकार के उपचार के प्रति संवेदनशील त्रुटियाँ प्रकृति में क्षणिक होती हैं। उदाहरण के लिए, किसी वेब सेवा या RMI सेवा को किया गया रिमोट कॉल जो नेटवर्क गड़बड़ी के कारण विफल हो जाता है, या डेटाबेस अपडेट में DeadLockLoserException जो थोड़ी प्रतीक्षा के बाद स्वयं हल हो सकता है। ऐसे ऑपरेशनों के पुनः प्रयास को स्वचालित करने के लिए, Spring Retry में RetryOperations रणनीति है। RetryOperations इंटरफ़ेस की परिभाषा निम्नलिखित है:

public interface RetryOperations {

    <T> T execute(RetryCallback<T> retryCallback) throws Exception;

    <T> T execute(RetryCallback<T> retryCallback, RecoveryCallback<T> recoveryCallback)
        throws Exception;

    <T> T execute(RetryCallback<T> retryCallback, RetryState retryState)
        throws Exception, ExhaustedRetryException;

    <T> T execute(RetryCallback<T> retryCallback, RecoveryCallback<T> recoveryCallback,
        RetryState retryState) throws Exception;

}

मूल कॉलबैक एक सरल इंटरफ़ेस है जो आपको पुनः प्रयास किए जाने वाले कुछ बिज़नेस लॉजिक सम्मिलित करने देता है:

public interface RetryCallback<T> {

    T doWithRetry(RetryContext context) throws Throwable;

}

कॉलबैक को आज़माया जाता है, और, यदि यह विफल हो जाता है (एक Exception फेंककर), तो इसे तब तक पुनः प्रयास किया जाता है जब तक कि यह सफल न हो जाए या कार्यान्वयन निरस्त करने का निर्णय न ले ले। RetryOperations इंटरफ़ेस में कई ओवरलोडेड execute विधियाँ हैं, जो तब रिकवरी के विभिन्न उपयोग मामलों से निपटने के लिए हैं जब सभी पुनः प्रयास प्रयास समाप्त हो जाते हैं, और पुनः प्रयास स्थिति से निपटने के लिए हैं, जो क्लाइंट्स और कार्यान्वयन को कॉल्स के बीच जानकारी संग्रहीत करने देती है (इस पर बाद में अधिक जानकारी)।

RetryOperations का सबसे सरल सामान्य-उद्देश्य कार्यान्वयन RetryTemplate है। निम्नलिखित उदाहरण दिखाता है कि इसका उपयोग कैसे करें:

RetryTemplate template = new RetryTemplate();

TimeoutRetryPolicy policy = new TimeoutRetryPolicy();
policy.setTimeout(30000L);

template.setRetryPolicy(policy);

Foo result = template.execute(new RetryCallback<Foo>() {

    public Foo doWithRetry(RetryContext context) {
        // Do stuff that might fail, e.g. webservice operation
        return result;
    }

});

पूर्ववर्ती उदाहरण में, हम एक वेब सेवा कॉल निष्पादित करते हैं और परिणाम उपयोगकर्ता को लौटाते हैं। यदि वह कॉल विफल हो जाती है, तो टाइमआउट तक पहुँचने तक इसे पुनः प्रयास किया जाता है।

संस्करण 1.3 से, RetryTemplate का fluent कॉन्फ़िगरेशन भी उपलब्ध है, जैसा कि निम्नलिखित है:

RetryTemplate.builder()
      .maxAttempts(10)
      .exponentialBackoff(100, 2, 10000)
      .retryOn(IOException.class)
      .traversingCauses()
      .build();

RetryTemplate.builder()
      .fixedBackoff(10)
      .withinMillis(3000)
      .build();

RetryTemplate.builder()
      .infiniteRetry()
      .retryOn(IOException.class)
      .uniformRandomBackoff(1000, 3000)
      .build();

RetryContext का उपयोग करना

RetryCallback के लिए मेथड पैरामीटर एक RetryContext है। कई कॉलबैक कॉन्टेक्स्ट को अनदेखा करते हैं। हालाँकि, यदि आवश्यक हो, तो आप इसे इटरेशन की अवधि के लिए डेटा संग्रहीत करने के लिए एक एट्रिब्यूट बैग के रूप में उपयोग कर सकते हैं।

यदि उसी थ्रेड में कोई नेस्टेड रीट्राई प्रगति पर है, तो RetryContext का एक पैरेंट कॉन्टेक्स्ट होता है। पैरेंट कॉन्टेक्स्ट कभी-कभी ऐसे डेटा को संग्रहीत करने के लिए उपयोगी होता है जिसे execute के कॉल्स के बीच साझा करने की आवश्यकता होती है।

RecoveryCallback का उपयोग करना

जब रीट्राई समाप्त हो जाता है, तो RetryOperations नियंत्रण को एक भिन्न कॉलबैक को पास कर सकता है: RecoveryCallback। इस सुविधा का उपयोग करने के लिए, क्लाइंट कॉलबैक को एक साथ उसी मेथड में पास कर सकते हैं, जैसा कि निम्नलिखित उदाहरण में दिखाया गया है:

Foo foo = template.execute(new RetryCallback<Foo>() {
    public Foo doWithRetry(RetryContext context) {
        // business logic here
    },
  new RecoveryCallback<Foo>() {
    Foo recover(RetryContext context) throws Exception {
          // recover logic here
    }
});

यदि व्यावसायिक तर्क टेम्पलेट के निरस्त करने का निर्णय लेने से पहले सफल नहीं होता है, तो क्लाइंट को रिकवरी कॉलबैक के माध्यम से कुछ वैकल्पिक प्रोसेसिंग करने का अवसर दिया जाता है।

स्टेटलेस रीट्राई

सबसे सरल स्थिति में, रीट्राई केवल एक while लूप है: RetryTemplate तब तक प्रयास करता रह सकता है जब तक कि वह सफल या विफल न हो जाए। RetryContext में यह निर्धारित करने के लिए कुछ स्थिति होती है कि रीट्राई करना है या निरस्त करना है। हालाँकि, यह स्थिति स्टैक पर होती है, और इसे कहीं भी वैश्विक रूप से संग्रहीत करने की आवश्यकता नहीं होती है। इसलिए, हम इसे "स्टेटलेस रीट्राई" कहते हैं। स्टेटलेस और स्टेटफुल रीट्राई के बीच का अंतर RetryPolicy के कार्यान्वयन में निहित है (RetryTemplate दोनों को संभाल सकता है)। स्टेटलेस रीट्राई में, कॉलबैक हमेशा उसी थ्रेड में निष्पादित होता है जिसमें रीट्राई पर विफलता हुई थी।

स्टेटफुल रीट्राई