Spring WebClient प्रॉक्सी त्रुटी: रिअॅक्टिव्ह हाताळणी विरुद्ध लॉगिंग
प्रॉक्सी अयशस्वी झाल्यावर WebClient चा रिअॅक्टिव्ह त्रुटी संकेत, ट्रान्सपोर्ट लॉगिंग आणि HTTP स्थिती हाताळणी वेगळी करा.
ट्रान्सपोर्ट अयशस्वी प्रॉक्सी कनेक्शन लॉग करू शकतो, तर अनुप्रयोगही रिअॅक्टिव्ह त्रुटी प्राप्त करून हाताळतो. केवळ लॉग नोंद हे सिद्ध करत नाही की अनुप्रयोगाचा हाताळणीकर्ता वगळला गेला.
प्रत्यक्षात सदस्यता घेतलेल्या साखळीतील त्रुटी संकेताचा मागोवा घ्या. केवळ Mono तयार करणाऱ्या कोडभोवतीचे try/catch नंतरच्या नेटवर्क अयशस्वीतेच्या हाताळणीपेक्षा वेगळी व्याप्ती आहे.
| ऑपरेटर | परिणाम |
|---|---|
| doOnError | त्रुटी सुरू असताना दुष्परिणाम करतो |
| onErrorMap | एका त्रुटीचे दुसऱ्या त्रुटीत रूपांतर करतो |
| onErrorResume | पर्यायी प्रकाशकाकडे वळतो |
अनुप्रयोगाला आवश्यक असलेले वर्तन निवडा. मेट्रिक नोंदवण्यासाठी बनावट यशस्वी सामग्री परत देण्याची गरज नाही. पर्यायी प्रतिसाद अनुप्रयोगाचा जाणीवपूर्वक निकाल असावा, अयशस्वी मार्ग लपवण्याचा उपाय नाही.
ट्रान्सपोर्ट अपवाद आणि प्राप्त HTTP त्रुटी स्थिती यातही फरक करा. प्रॉक्सी कनेक्शन सामान्य गंतव्य प्रतिसाद अस्तित्वात येण्यापूर्वीच अयशस्वी होऊ शकते, त्यामुळे HTTP स्थिती हाताळणीकर्त्याकडे तपासण्यासाठी काहीच नसू शकते. खालच्या स्तरावरील अयशस्वीतेचे निदान करताना WebClientRequestException चे कारण जपून ठेवा.
निकाल समजल्यानंतरच लॉगिंग समायोजित करा. संपूर्ण ट्रान्सपोर्ट लॉगर बंद केल्यास नंतरच्या टाइमआउट, TLS समस्या किंवा प्रमाणीकरण अयशस्वीतेसाठी आवश्यक पुरावे काढले जाऊ शकतात, रिअॅक्टिव्ह पाइपलाइनचे वर्तन न बदलता.