Spring WebClient میں پراکسی کی خرابیاں: ردِ عمل کی کارروائی بمقابلہ لاگنگ
پراکسی کی ناکامی کے دوران WebClient کا ردِ عمل والا نقصان سگنل، ٹرانسپورٹ لاگنگ اور HTTP اسٹیٹس کی کارروائی میں فرق کریں۔
ٹرانسپورٹ ناکام پراکسی کنکشن کو لاگ میں درج کر سکتا ہے جبکہ ایپلیکیشن بھی وہ ردِ عمل والا نقصان وصول کر کے سنبھالتی ہے۔ صرف لاگ اندراج یہ ثابت نہیں کرتا کہ ایپلیکیشن کا ہینڈلر چھوڑ دیا گیا۔
نقصان کے سگنل کی اُس زنجیر میں پیروی کریں جس کی واقعی سبسکرپشن ہوتی ہے۔ محض Mono بنانے والے کوڈ کے گرد try/catch بعد میں آنے والی نیٹ ورک ناکامی سنبھالنے سے مختلف دائرہ ہے۔
| آپریٹر | اثر |
|---|---|
| doOnError | نقصان جاری رہنے کے دوران ضمنی اثر کرتا ہے |
| onErrorMap | ایک نقصان کو دوسرے نقصان میں بدلتا ہے |
| onErrorResume | متبادل ناشر کی طرف منتقل ہوتا ہے |
وہ رویہ چنیں جس کی ایپلیکیشن کو ضرورت ہے۔ میٹرک ریکارڈ کرنے کے لیے جعلی کامیاب مواد واپس کرنا ضروری نہیں۔ متبادل جواب ایپلیکیشن کا سوچا سمجھا نتیجہ ہونا چاہیے، ناکام راستہ چھپانے کا طریقہ نہیں۔
ٹرانسپورٹ کی استثنائی حالتیں موصول شدہ HTTP نقصان اسٹیٹس سے بھی الگ رکھیں۔ پراکسی کنکشن عام منزل کے جواب کے وجود سے پہلے ناکام ہو سکتا ہے، اس لیے HTTP اسٹیٹس ہینڈلر کے پاس جانچنے کو کچھ نہ ہو۔ نچلی سطح کی ناکامی کی تشخیص کرتے وقت WebClientRequestException کی وجہ محفوظ رکھیں۔
لاگنگ میں تبدیلی نتیجہ سمجھنے کے بعد ہی کریں۔ پورے ٹرانسپورٹ لاگر کو بند کرنا بعد کے ٹائم آؤٹ، TLS مسئلے یا توثیق کی ناکامی کے لیے ضروری شواہد ہٹا سکتا ہے، بغیر ردِ عمل والی پائپ لائن کے رویے کو بدلے۔