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

Reply via email to