On 23/09/2020 15:50, Berneburg, Cris J. - US wrote: > 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"?
Not reducing the number of streams below the maximum number of concurrent streams. > Would aggressiveness depend on system load? Possibly. The less it does so, the better. But, for example, if Tomcat is processing 10k req/s just keeping track of the last 30s is potentially 300k streams. How to do that efficiently for all usage patterns is a problem that needs some thought. > mt> - that under high load a "significant period" becomes a > mt> few milliseconds > > Sounds like "significant period" varies depending on system load. At the moment there is a fairly direct inverse relationship. Ideally there should be no relationship. Not sure how achievable that is at the moment. > 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? Potentially. > b. De-reference other objects no longer needed? Hmm... that might lead to > NPE's and thus unnecessary null checking. Tried that. Lots of NPE regressions to the point that I reverted the change to look for a better solution. > c. Or did you already have something in mind? A form of a). I'm looking at this now. > 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? Both. I started to look at this a while ago but it gets very complex quite quickly. It would be simpler if we were just serving static content. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
