更新 1：似乎使用綁定到 HTTP 請求的上下文可能會(huì)導(dǎo)致“上下文取消”錯(cuò)誤。但是，使用 context.Background() 作為父母似乎工作正常。 // This works, no 'context canceled' errors ctx, cancel := context.WithTimeout(context.Background(), 100*time.Second) // However, this creates 'context canceled' errors under mild load // ctx, cancel := context.WithTimeout(r.Context(), 100*time.Second) defer cancel() app.Insert(ctx, record)（更新了下面的代碼示例以生成一個(gè)獨(dú)立的重現(xiàn)示例）在 go 中，我有一個(gè)類似于以下代碼的 http 處理程序。在對該端點(diǎn)的第一個(gè) HTTP 請求中，我收到一個(gè)context cancelled錯(cuò)誤。但是，數(shù)據(jù)實(shí)際上是插入到數(shù)據(jù)庫中的。在對該端點(diǎn)的后續(xù)請求中，不會(huì)出現(xiàn)此類錯(cuò)誤，并且數(shù)據(jù)也已成功插入數(shù)據(jù)庫。問題：我context是否在 http 處理程序和pgx QueryRow 方法之間正確設(shè)置和傳遞？（如果沒有，有更好的方法嗎？）如果將此代碼復(fù)制到 main.go 并運(yùn)行g(shù)o run main.go，轉(zhuǎn)到localhost:4444/create并按住ctrl-R以產(chǎn)生輕微的負(fù)載，您應(yīng)該會(huì)看到產(chǎn)生了一些上下文取消的錯(cuò)誤。
1 回答
動(dòng)漫人物
TA貢獻(xiàn)1815條經(jīng)驗(yàn) 獲得超10個(gè)贊
TLDR：r.Context()在生產(chǎn)中使用效果很好，使用瀏覽器進(jìn)行測試是個(gè)問題。
一個(gè) HTTP 請求獲得它自己的上下文，當(dāng)請求完成時(shí)該上下文被取消。這是一個(gè)特性，而不是一個(gè)錯(cuò)誤。當(dāng)請求被客戶端中斷或超時(shí)時(shí)，開發(fā)人員應(yīng)該使用它并優(yōu)雅地關(guān)閉執(zhí)行。例如，取消的請求可能意味著客戶端永遠(yuǎn)不會(huì)看到響應(yīng)（交易結(jié)果），開發(fā)人員可以決定回滾該交易。
在生產(chǎn)中，對于正常設(shè)計(jì)/構(gòu)建的 API，請求取消不會(huì)經(jīng)常發(fā)生。通常，流程由服務(wù)器控制，服務(wù)器在取消請求之前返回結(jié)果。多個(gè)Client請求不會(huì)互相影響，因?yàn)樗麄兊玫姜?dú)立的go-routine和context。同樣，我們正在談?wù)撜ＴO(shè)計(jì)/構(gòu)建應(yīng)用程序的快樂路徑。您的示例應(yīng)用程序看起來不錯(cuò)，應(yīng)該可以正常工作。
問題是我們?nèi)绾螠y試應(yīng)用程序。我們使用瀏覽器并刷新單個(gè)瀏覽器會(huì)話，而不是創(chuàng)建多個(gè)獨(dú)立的請求。我沒有檢查到底發(fā)生了什么，但假設(shè)瀏覽器終止了現(xiàn)有請求以便在您單擊時(shí)運(yùn)行新請求ctrl-R。服務(wù)器看到該請求終止并將其作為上下文取消傳達(dá)給您的代碼。
嘗試使用curl或創(chuàng)建獨(dú)立請求的其他一些腳本/實(shí)用程序來測試您的代碼。我相信在那種情況下您不會(huì)看到取消。
- 1 回答
- 0 關(guān)注
- 120 瀏覽
添加回答
舉報(bào)
0/150
提交
取消