Spring WebClient ਵਿੱਚ ਪ੍ਰੌਕਸੀ ਗਲਤੀਆਂ: ਰਿਐਕਟਿਵ ਹੈਂਡਲਿੰਗ ਬਨਾਮ ਲੌਗਿੰਗ
ਪ੍ਰੌਕਸੀ ਫੇਲ ਹੋਣ ਵੇਲੇ WebClient ਦਾ ਰਿਐਕਟਿਵ ਗਲਤੀ ਸੰਕੇਤ, ਟ੍ਰਾਂਸਪੋਰਟ ਲੌਗਿੰਗ ਅਤੇ HTTP ਸਥਿਤੀ ਹੈਂਡਲਿੰਗ ਨੂੰ ਵੱਖਰਾ ਕਰੋ।
ਟ੍ਰਾਂਸਪੋਰਟ ਫੇਲ ਹੋਏ ਪ੍ਰੌਕਸੀ ਕਨੈਕਸ਼ਨ ਨੂੰ ਲੌਗ ਕਰ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਵੀ ਰਿਐਕਟਿਵ ਗਲਤੀ ਪ੍ਰਾਪਤ ਕਰਕੇ ਸੰਭਾਲਦੀ ਹੈ। ਸਿਰਫ਼ ਲੌਗ ਐਂਟਰੀ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਹੈਂਡਲਰ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਸੀ।
ਅਸਲ ਵਿੱਚ ਸਬਸਕ੍ਰਾਈਬ ਹੋਣ ਵਾਲੀ ਚੇਨ ਵਿੱਚ ਗਲਤੀ ਸੰਕੇਤ ਦਾ ਪਤਾ ਲਗਾਓ। ਸਿਰਫ਼ Mono ਬਣਾਉਣ ਵਾਲੇ ਕੋਡ ਦੁਆਲੇ try/catch ਬਾਅਦ ਦੀ ਨੈੱਟਵਰਕ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਸੰਭਾਲ ਨਾਲੋਂ ਵੱਖਰੀ ਹੱਦ ਹੈ।
| ਓਪਰੇਟਰ | ਪ੍ਰਭਾਵ |
|---|---|
| doOnError | ਗਲਤੀ ਜਾਰੀ ਰਹਿੰਦਿਆਂ ਸਾਈਡ-ਇਫੈਕਟ ਕਰਦਾ ਹੈ |
| onErrorMap | ਇੱਕ ਗਲਤੀ ਨੂੰ ਦੂਜੀ ਗਲਤੀ ਵਿੱਚ ਬਦਲਦਾ ਹੈ |
| onErrorResume | ਬਦਲਵੇਂ ਪ੍ਰਕਾਸ਼ਕ ਵੱਲ ਬਦਲ ਜਾਂਦਾ ਹੈ |
ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਜੋ ਵਿਵਹਾਰ ਚਾਹੀਦਾ ਹੈ ਉਹ ਚੁਣੋ। ਮੈਟ੍ਰਿਕ ਰਿਕਾਰਡ ਕਰਨ ਲਈ ਨਕਲੀ ਸਫਲ ਸਮੱਗਰੀ ਵਾਪਸ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਬਦਲਵਾਂ ਜਵਾਬ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਦਿੱਤਾ ਨਤੀਜਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਫੇਲ ਹੋਏ ਰਸਤੇ ਨੂੰ ਲੁਕਾਉਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ।
ਟ੍ਰਾਂਸਪੋਰਟ ਐਪਵਾਦਾਂ ਨੂੰ ਪ੍ਰਾਪਤ HTTP ਗਲਤੀ ਸਥਿਤੀਆਂ ਤੋਂ ਵੀ ਵੱਖਰਾ ਕਰੋ। ਪ੍ਰੌਕਸੀ ਕਨੈਕਸ਼ਨ ਆਮ ਮੰਜ਼ਿਲ ਜਵਾਬ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ HTTP ਸਥਿਤੀ ਹੈਂਡਲਰ ਕੋਲ ਜਾਂਚਣ ਲਈ ਕੁਝ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਹੇਠਲੇ ਪੱਧਰ ਦੀ ਫੇਲ੍ਹ ਦਾ ਨਿਦਾਨ ਕਰਦਿਆਂ WebClientRequestException ਦਾ ਕਾਰਨ ਸੰਭਾਲ ਕੇ ਰੱਖੋ।
ਨਤੀਜਾ ਸਮਝਣ ਤੋਂ ਬਾਅਦ ਹੀ ਲੌਗਿੰਗ ਵਿੱਚ ਤਬਦੀਲੀ ਕਰੋ। ਪੂਰਾ ਟ੍ਰਾਂਸਪੋਰਟ ਲੌਗਰ ਬੰਦ ਕਰਨ ਨਾਲ ਬਾਅਦ ਦੇ ਟਾਈਮਆਉਟ, TLS ਸਮੱਸਿਆ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਫੇਲ੍ਹ ਲਈ ਲੋੜੀਂਦੇ ਸਬੂਤ ਹਟ ਸਕਦੇ ਹਨ, ਰਿਐਕਟਿਵ ਪਾਈਪਲਾਈਨ ਦਾ ਵਿਵਹਾਰ ਬਦਲੇ ਬਿਨਾਂ।