記一次feign調(diào)用JSON parse異常

com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'password': was expecting ('true', 'false' or 'null')

at [Source: java.io.PushbackInputStream@d3211c6; line: 1, column: 10]


以上為主要報錯內(nèi)容,開始進(jìn)入檢查,走起。

使用postman單獨調(diào)用該feign正常,確定應(yīng)該是調(diào)用方參數(shù)封裝問題

檢查調(diào)用方參數(shù)與被調(diào)用方參數(shù)是否一致,檢查后是一致的,這就有點坑爹了。

啟動服務(wù)進(jìn)入debug,嗯,miamiamia,斷點逐一進(jìn)入,feign調(diào)用意料之中的報錯。

檢查調(diào)用方請求頭設(shè)置,application/json,確認(rèn),沒毛病。

有點頭大了檢查git修改記錄,貌似也沒啥問題。

回想最近是否有組件修改,想起來了,昨天做了feign調(diào)用請求頭轉(zhuǎn)發(fā)實現(xiàn)了RequestInterceptor接口進(jìn)行了請求頭的一些處理,debug進(jìn)斷點看一下是否請求頭被篡改了,打印restTemplate中請求頭信息,application/json,沒毛病再往下看,看到問題了。


該代碼修改請求參數(shù)

因為項目要做多租戶改造,時間比較緊張,這個組件網(wǎng)上找了個測了一下可用就發(fā)上去了,結(jié)果效果十分感人,看了有一會

參考了簡書里的地址傳送門

考慮到使用這種方式要修改為信號量的模式,并沒有完全參考上面那位作者的做法,而是繼承了HystrixConcurrencyStrategy進(jìn)行了自定義了隔離策略,改動量小一點,畢竟時間緊張,這是個一聽就讓人有種淡淡的憂傷的話

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

友情鏈接更多精彩內(nèi)容