Closed JudgeGregg closed 3 years ago
Thanks @JudgeGregg for your analysis. I am not sure how necessary it is to patch this (maybe in some scenarios reusing existing connection is necessary, but I haven't personally built any system that run out of TCP connections) 😄 .
Let me spend some time investigate TCP connection reuse and I'll see what we can do here. Thanks for reporting this issue.
Thanks for your report. Due to time limit on my side I won't be able to maintain this package. Please consider using some other library like https://github.com/rkl-/digest. Thanks for your support!
I think the TCP connections are not reused with the current code:
I patched the client according to: https://blog.golang.com/http-tracing
And here's what I got:
I believe the problem is twofold:
https://golang.org/src/net/http/transport.go?h=http.Transport
By applying the following patch:
we get the following:
@@ -129,6 +139,7 @@ func (dr DigestRequest) executeNewDigest(resp http.Response) (resp2 *http.Resp )
io.Copy(ioutil.Discard, resp.Body) resp.Body.Close()
if waString = resp.Header.Get("WWW-Authenticate"); waString == "" {
Then we get:
The problem with hanging connections is that under a heavy load, the client can run out of TCP connections, since they're all in a TIME-WAIT state.
I think problem 2 is easy to solve (simply discard the resp.Body) I have no idea how to solve problem 1 while still keeping a configurable client, though.
Sorry for that long text, and thank you very much for your work on this useful library :)