Transport သည် မအောင်မြင်သော proxy ချိတ်ဆက်မှုကို log တွင် မှတ်တမ်းတင်နိုင်ပြီး application ကလည်း reactive အမှားကို လက်ခံကာ ကိုင်တွယ်သည်။ log မှတ်တမ်း တစ်ခုတည်းက application ၏ handler ကို ကျော်သွားသည်ဟု သက်သေမပြနိုင်ပါ။

အမှန်တကယ် subscribe လုပ်သော ကွင်းဆက်အတွင်း အမှားအချက်ပြကို လိုက်ကြည့်ပါ။ Mono ကို ဖန်တီးရုံသာ လုပ်သော ကုဒ်ကို ဝိုင်းထားသည့် try/catch သည် နောက်ပိုင်း network မအောင်မြင်မှုကို ကိုင်တွယ်ခြင်းနှင့် မတူညီသော နယ်ပယ်ဖြစ်သည်။

အော်ပရေတာအကျိုးသက်ရောက်မှု
doOnErrorအမှား ဆက်ဖြစ်နေစဉ် ဘေးထွက်အကျိုးသက်ရောက်မှုကို လုပ်ဆောင်သည်
onErrorMapအမှားတစ်ခုကို အခြားအမှားတစ်ခုအဖြစ် ပြောင်းလဲသည်
onErrorResumeအစားထိုး ထုတ်ဝေသူသို့ ပြောင်းသည်

Application လိုအပ်သော အပြုအမူကို ရွေးပါ။ metric မှတ်တမ်းတင်ရန် အတုအယောင် အောင်မြင်သည့် အကြောင်းအရာ ပြန်ပေးရန် မလိုအပ်ပါ။ အစားထိုး တုံ့ပြန်မှုသည် application ၏ တမင်ရည်ရွယ်သော ရလဒ် ဖြစ်သင့်ပြီး မအောင်မြင်သော လမ်းကြောင်းကို ဖုံးကွယ်သည့် နည်းလမ်း မဟုတ်ပါ။

Transport ခြွင်းချက်များနှင့် လက်ခံရရှိသော HTTP အမှား status များကိုလည်း ခွဲခြားပါ။ Proxy ချိတ်ဆက်မှုသည် သာမန် ဦးတည်ရာ တုံ့ပြန်မှု မရှိမီ မအောင်မြင်နိုင်သောကြောင့် HTTP status handler တွင် စစ်ဆေးရန် ဘာမှ မရှိနိုင်ပါ။ အောက်ခြေ အဆင့် မအောင်မြင်မှုကို စစ်ဆေးရာတွင် WebClientRequestException ၏ အကြောင်းရင်းကို ထိန်းသိမ်းပါ။

ရလဒ်ကို နားလည်ပြီးမှသာ logging ကို ချိန်ညှိပါ။ transport logger တစ်ခုလုံးကို ပိတ်လိုက်ခြင်းသည် နောက်ပိုင်း timeout၊ TLS ပြဿနာ သို့မဟုတ် အတည်ပြုခြင်း မအောင်မြင်မှုအတွက် လိုအပ်သော အထောက်အထားများကို ဖယ်ရှားနိုင်ပြီး reactive pipeline ၏ အပြုအမူကို မပြောင်းလဲပါ။

ဆက်စပ်ဆောင်းပါးများ