I still think this is a problem, but I don't think it's the over_max_streams problem I'm hitting. I checked all the exit paths and they all have error counter metrics on them, except for one (https://golang.org/cl/353031), which I doubt we're hitting, as CONNECT requests should be unable to make it to our backend.
I continue to hunt a stream accounting bug in either the Go HTTP/2 transport and/or server. Reading code again now, I noticed:
... where that
newStreamcall is what's responsible for incrementing the stream count:
(that's what's ultimately causing the
return sc.countError("over_max_streams", streamError(id, ErrCodeProtocol))I'm hitting)
But just after that
newStreamcall are two error exit paths:
return errerrors are suspect. If those happen, then
curClientStreamscan be left incremented, never to be decremented again.
The decrement happens in
(*serverConn).closeStream, which is called from:
processResetStream, reading a RSTStream frame from the client (e.g. they canceled the request)
wroteFrame, called after a frame write is successful, including handler panics. But if we
return errabove before starting the handler, we can't ever write anything, as the handler never runs.
I'm not sure whether this is what we're hitting yet, but it looks suspicious.
The text was updated successfully, but these errors were encountered: