Squid retry_on_error: स्थिती कोड आणि पर्यायी मार्ग

Squid मध्ये retry_on_error नावाचा पर्याय आहे, पण नाव त्याच्या उपयुक्त अर्थापेक्षा मोठे आहे. पान काम करेपर्यंत प्रत्येक अयशस्वी विनंती अमर्यादपणे पुनरावृत्ती होईल असा त्याचा अर्थ नाही.

हा निर्देश समर्थित करणाऱ्या आवृत्त्यांमध्ये तो डीफॉल्टनुसार बंद आहे. दस्तऐवजीकृत पुनरावृत्ती यादी 403, 500, 501, 502, 503 आणि 504 आहे, आणि तो विनंती दुसऱ्या कार्यरत गंतव्याद्वारे वापरून पाहतो. पर्यायी फॉरवर्डिंग मार्ग असलेल्या पदानुक्रमात हे विशेषतः महत्त्वाचे आहे. हे केवळ त्याच सॉकेटकडून त्याच सर्व्हरकडे वेळेनुसार पुनःप्रयत्न नाही.

आधी अपयशाला नाव द्या

प्रॉक्सीशी जोडताना नकार, प्रॉक्सी प्रमाणीकरण अपयश, मूळकडून HTTP त्रुटी आणि वितरण सुरू झाल्यानंतर कापलेला प्रतिसाद या सर्वांना समान पुनःप्रयत्नाची संधी मिळत नाही. एक सेटिंग चारही समान पद्धतीने हाताळेल अशी अपेक्षा करू नका.

खाजगी निर्गमासाठी, पर्यायी मार्ग स्वीकारार्ह आहे का हे देखील ठरवा. दुसऱ्या पालकाचा दुसरा सार्वजनिक स्रोत पत्ता, प्रमाणीकरण धोरण किंवा नेटवर्क स्थान असू शकते. त्या पर्यायातून मिळणारे यश पहिला पालक निवडण्याचे कारण भंगवू शकते.

अनुप्रयोग क्रिया आणखी एक चिंता आणतात: विनंतीची पुनरावृत्ती केल्यास तिचा परिणामही पुनरावृत्ती होऊ शकतो. क्लायंट आणि सर्व्हरला योग्य पुनःप्रयत्न अर्थशास्त्र आवश्यक आहे, विशेषतः डेटा तयार करणाऱ्या किंवा बदलणाऱ्या क्रियांसाठी. प्रॉक्सी सेटिंग अनिश्चित परिणामांच्या अनुप्रयोग-स्तरीय हाताळणीचा पर्याय नाही.

तुमच्या नेमक्या आवृत्तीसाठी निर्देश वाचा; संदर्भ उपलब्धता आणि डीफॉल्ट वर्तनाची यादी करतो. तसेच विनंतीची मुदत आणि वापरकर्त्याला दिसणारी एकूण प्रतीक्षा लक्षात ठेवा. अतिरिक्त फॉरवर्डिंग प्रयत्न चांगला निकाल न देता उर्वरित वेळ वापरू शकतो.

अधूनमधून येणाऱ्या अपयशांची तपासणी करताना स्थिती, निवडलेला पालक किंवा गंतव्य आणि प्रयत्नांचा क्रम नोंदवा. अन्यथा पुनरावृत्तीमुळे वारंवार होणारी राउटिंग समस्या सामान्यतः संथ वेबसाइटसारखी दिसू शकते आणि प्रत्यक्षात अयशस्वी झालेला मार्ग लपू शकतो.