Грешки на прокси во Spring WebClient: реактивно ракување наспроти логирање
Разликувајте го реактивниот сигнал за грешка на WebClient, логирањето на транспортот и ракувањето со HTTP статусот при неуспех на прокси.
Транспортот може да забележи неуспешна прокси врска додека апликацијата исто така ја прима и обработува реактивната грешка. Самиот запис во логот не докажува дека ракувачот на апликацијата бил прескокнат.
Следете го сигналот за грешка во синџирот што навистина се претплатува. try/catch околу код што само гради Mono е друг обем од обработката на подоцнежен мрежен неуспех.
| Оператор | Ефект |
|---|---|
| doOnError | Извршува спореден ефект додека грешката продолжува |
| onErrorMap | Претвора грешка во друга грешка |
| onErrorResume | Префрла на алтернативен издавач |
Изберете го однесувањето што му е потребно на апликацијата. Запишувањето метрика не бара враќање лажно успешна содржина. Алтернативниот одговор треба да биде намерен резултат на апликацијата, а не начин да се скрие неуспешна рута.
Исто така разликувајте ги транспортните исклучоци од примените HTTP статуси за грешка. Прокси врската може да не успее пред да постои вообичаен одговор од одредиштето, па ракувачот со HTTP статус може да нема што да прегледа. Зачувајте ја причината за WebClientRequestException при дијагностицирање на понискиот неуспех.
Прилагодете го логирањето само откако ќе го разберете исходот. Исклучувањето на целиот транспортен логер може да отстрани докази потребни за подоцнежен тајмаут, TLS проблем или неуспех при автентикација, без да го промени однесувањето на реактивниот тек.