On 22/09/2020 13:47, Berneburg, Cris J. - US wrote: > Hi Mark > > As with most topics here, I struggle to understand what is being discussed. > :-) So please bear with me. > >> improving how Tomcat handles traffic like this. >> >> Looks like Tomcat could prune the closed streams >> less aggressively. >> >> At the moment it waits until there are >> maxConcurrentStreams + 10% in the map and then: >> - removes all closed streams without children >> - [snip] with children [snip] >> - [snip] closed final streams [snip] >> >> [snip] the size of the map increases to ~110 and >> then drops to ~5, increases to ~110 and repeats. >> >> I'm currently thinking about different pruning >> strategies. The associated memory footprint is >> also part of my thinking. > > TC thinks the stream should be closed when the client thinks the stream is > still open? Basically RST_STREAM is a keep-alive?
No. The stream closed cleanly. The client is sending RST_STREAM due to what is suspected to be a client bug. RFC 7540 says the server must ignore such frames and can, if a frame is received a significant period after the stream closed, treat it as a protocol error (and close the connection). Separately, the server should (as per the RFC) retain state for closed streams to support prioritisation. Currently Tomcat uses a single Map to track the state of closed streams for priority and to identify streams have been closed for an *in*significant amount of time. The issues immediately at hand are: - how that Map is pruned (it is currently too aggressive) - that under high load a "significant period" becomes a few milliseconds Also in the mix: - currently memory footprint of a closed stream is much larger than it needs to be - while we have all the plumbing to correctly determine relative priority and use it when allocating window updates in the case where the connection flow control window is smaller than the total data the streams want to send - we don't use it to prioritise streams when flow control windows are not an issue Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
