Hi Mark Thanks for taking the time to explain that to me. :-)
A few more questions, if you don't mind. cjb> TC thinks the stream should be closed when the client cjb> thinks the stream is still open? Basically RST_STREAM cjb> is a keep-alive? mt> No. The stream closed cleanly. The client is sending mt> RST_STREAM due to what is suspected to be a client bug. mt> RFC 7540 says the server must ignore such frames and can, mt> if a frame is received a significant period after the mt> stream closed, treat it as a protocol error (and close mt> the connection). mt> Separately, the server should (as per the RFC) retain mt> state for closed streams to support prioritisation. mt> Currently Tomcat uses a single Map to track the state of mt> closed streams for priority and to identify streams have mt> been closed for an *in*significant amount of time. mt> The issues immediately at hand are: mt> - how that Map is pruned (it is currently too aggressive) What would you consider "less aggressive"? Would aggressiveness depend on system load? mt> - that under high load a "significant period" becomes a mt> few milliseconds Sounds like "significant period" varies depending on system load. mt> currently memory footprint of a closed stream is much mt> larger than it needs to be How could the closed stream footprint be reduced? Could the structure holding a closed stream: a. Be replaced with a smaller one? b. De-reference other objects no longer needed? Hmm... that might lead to NPE's and thus unnecessary null checking. c. Or did you already have something in mind? mt> while we have all the plumbing to correctly determine mt> relative priority and use it when allocating window mt> updates in the case where the connection flow control mt> window is smaller than the total data the streams want mt> to send - we don't use it to prioritise streams when mt> flow control windows are not an issue Is that an FYI or a to-do? -- 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org