arturobernalg opened a new pull request, #731: URL: https://github.com/apache/httpcomponents-core/pull/731
PING and SETTINGS acknowledgements, `WINDOW_UPDATE` and `RST_STREAM` frames generated in response to peer frames were queued without bound when the output could not be flushed as fast as the peer sent them. Measured on master with a single connection and the default `H2ServerBootstrap` configuration, 1,500,000 PING frames (about 25 MB): the output queue reached 1.3 to 1.5 million entries and the heap grew by 170 to 194 MB. The same happens when the peer reads the responses, fast or slowly, as the input is processed faster than the output is written. SETTINGS frames behave the same. Empty DATA frames do not amplify, as `WINDOW_UPDATE` is throttled by the flow control low mark. `AbstractH2StreamMultiplexer` now counts the control frames pending output and terminates the connection with `GOAWAY(ENHANCE_YOUR_CALM)` beyond `H2Config#getMaxControlFrames`, 1000 by default, zero disables the limit. The counter holds the frames currently queued and goes down as they are flushed, so a peer that keeps up is never limited. It follows `maxContinuations`. `H2Config#copy` dropped `maxContinuations`; it is copied now along with the new setting. Rapid reset (`HEADERS` followed by `RST_STREAM` repeated) is not addressed here. A single connection can force tens of thousands of stream setup and teardown cycles per second without reset accounting; that needs separate inbound accounting. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
