Spring WebClient প্রক্সি ত্রুটি: প্রতিক্রিয়াশীল হ্যান্ডলিং বনাম লগিং
প্রক্সি ব্যর্থতার সময় WebClient-এর প্রতিক্রিয়াশীল ত্রুটি সংকেত, ট্রান্সপোর্ট লগিং ও HTTP স্ট্যাটাস হ্যান্ডলিং আলাদা করুন।
একটি ট্রান্সপোর্ট ব্যর্থ প্রক্সি সংযোগ লগ করতে পারে, আবার অ্যাপ্লিকেশনও প্রতিক্রিয়াশীল ত্রুটিটি গ্রহণ করে হ্যান্ডল করে। শুধু লগ এন্ট্রি প্রমাণ করে না যে অ্যাপ্লিকেশনের হ্যান্ডলার বাদ পড়েছে।
যে চেইনটি সত্যিই সাবস্ক্রাইব হয়, সেই চেইনে ত্রুটি সংকেত অনুসরণ করুন। শুধু Mono তৈরি করা কোডের চারপাশের try/catch পরবর্তী নেটওয়ার্ক ব্যর্থতা হ্যান্ডল করার চেয়ে ভিন্ন পরিধি।
| অপারেটর | প্রভাব |
|---|---|
| doOnError | ত্রুটি চলতে থাকাকালে পার্শ্ব-প্রভাব সম্পন্ন করে |
| onErrorMap | একটি ত্রুটিকে অন্য ত্রুটিতে রূপান্তরিত করে |
| onErrorResume | বিকল্প প্রকাশকে সরে যায় |
অ্যাপ্লিকেশনের প্রয়োজনীয় আচরণ বেছে নিন। মেট্রিক রেকর্ড করতে নকল সফল কনটেন্ট ফেরত দেওয়ার দরকার নেই। বিকল্প প্রতিক্রিয়া হবে অ্যাপ্লিকেশনের ইচ্ছাকৃত ফলাফল, ব্যর্থ রুট লুকানোর উপায় নয়।
ট্রান্সপোর্ট ব্যতিক্রমগুলো প্রাপ্ত HTTP ত্রুটি স্ট্যাটাস থেকে আলাদা করুন। সাধারণ গন্তব্য প্রতিক্রিয়া তৈরি হওয়ার আগেই প্রক্সি সংযোগ ব্যর্থ হতে পারে, তাই HTTP স্ট্যাটাস হ্যান্ডলারের পরীক্ষা করার কিছু নাও থাকতে পারে। নিম্নস্তরের ব্যর্থতা নির্ণয়ের সময় WebClientRequestException-এর কারণ সংরক্ষণ করুন।
ফলাফল বুঝে নেওয়ার পরেই লগিং সমন্বয় করুন। সম্পূর্ণ ট্রান্সপোর্ট লগার বন্ধ করলে পরবর্তী টাইমআউট, TLS সমস্যা বা প্রমাণীকরণ ব্যর্থতার জন্য প্রয়োজনীয় প্রমাণ মুছে যেতে পারে, প্রতিক্রিয়াশীল পাইপলাইনের আচরণ না বদলেই।