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? So a passenger (client) discharges from a taxi and pays the driver (server), but asks the driver to wait (RST_STREAM), so the meter (stream) is still running. How long does the driver wait (timeout) before driving away? Does the driver honk the horn (send a wake-up packet) before looking for a new customer? Is the issue a matter of "how" or "when"? If TC receives RST_STREAM then restart the timeout clock. To prevent abuse allow a limited number of successive keep-alive frames. If a certain number of RST_STREAM's are received, aka threshold is reached, with nothing else occurring, then close the stream. That could be configurable. How about instead of a binary state of open or closed the state is trinary - open, stale, closed? - Open, don't prune. - Closed, prune. - Stale: a. Move to closed after timeout or too many RST_STREAM's. b. Consider open if receive useful traffic. Also, if there are multiple pruning strategies, allow a single method to be selected per connector config or for the whole TC instance. I hope this is helpful. If not, well, maybe at least it's educational. ;-) -- Cris Berneburg CACI Senior Software Engineer ________________________________ This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
