पुनः प्रयास

Glasswall Halo कई services से मिलकर बना है जो HTTP के बजाय asynchronous messages का उपयोग करके संचार करती हैं। इन services के लिए, हमने इस बारे में विचार किया है कि किसी message को process करते समय त्रुटि होने पर platform विफलता को कैसे संभालता है।

सिंक्रोनस API और एसिंक्रोनस API​

APIs, Glasswall Engine से response queues को subscribe करती हैं, हालांकि विफलता की स्थिति में http client को एक error response लौटाया जाएगा।

Engine सेवा​

आर्किटेक्चर RabbitMQ reply-to queues का उपयोग करते हुए request/response है। इसका मतलब है कि विफलता की स्थिति में, किसी संदेश को संभालते समय हम फिर भी विफलता का कारण शामिल करने वाला एक response message भेजते हैं।

रिपोर्ट एग्रीगेटर​

रिपोर्ट एग्रीगेटर एक मानक message consumer की तरह व्यवहार करता है और message retrying सक्षम करने के लिए अतिरिक्त कार्यक्षमता जोड़ी गई थी। सेवा पर दो configuration options मौजूद हैं।

Retrymessages एक bool है जिसका डिफ़ॉल्ट मान true है, जो messages को retry करने की कार्यक्षमता सक्षम करता है। यदि इसे बंद कर दिया जाए, तो सभी विफल messages को तुरंत dead letter queue में डाल दिया जाता है।

Messagettl एक integer है जो उन सेकंडों की संख्या दर्शाता है जितनी देर कोई message queue में रह सकता है। इसका उद्देश्य किसी विफल message के अनंत बार retry होने के कारण messages के जमा होने से बचना है। जब किसी message का time to live समाप्त हो जाता है, तो उसे dead letter queue में डाल दिया जाता है। कोड में डिफ़ॉल्ट मान 30 सेकंड है।

रिपोर्ट एग्रीगेटर की कार्यक्षमता क्लाइंट्स को उनकी फ़ाइलें प्राप्त होने के लिए महत्वपूर्ण नहीं है और इसका उपयोग aggregated report data तैयार करने के लिए किया जाता है। इसी कारण रिपोर्ट एग्रीगेटर message का dead lettering एक गंभीर विफलता नहीं माना जाता और dead letters को सहन किया जाता है (केवल अत्यधिक मामलों में)।