Thank you for the response Mark . Yes, with the default window size the requests process fine .
We were just attempting to reproduce the original issue that we are facing in production with version 9.0.38 where few connections go unresponsive for few seconds around the same time i.e. tomcat is able to receive the headers/partial data, but not responding back with window_update or sending ping frames and then after sometime tomcat sends PING frame and the connection processes further requests successfully . The GC looks fine at that time. Could there be any reasons that can cause this ? Please let us know. Thanks and Regards Arshiya Shariff -----Original Message----- From: Mark Thomas <ma...@apache.org> Sent: Wednesday, January 5, 2022 2:36 PM To: users@tomcat.apache.org Subject: Re: HTTP2 : WINDOW_UPDATE not sent on stream level On 05/01/2022 06:14, Arshiya Shariff wrote: > Hi Team, > On sending 3 requests of around 3KB size , we see that only the first > request has processed fine. The other 2 requests are waiting for more Data as > tomcat has not responded with WINDOW_UPDATE on stream level . Please help us > understand this behavior . > > Embedded tomcat version : 9.0.56 > The initial window size is set to 500, all other params are the tomcat > defaults . > HTTP2 port : 1080 > Client : JMeter > > I have placed the reproducer , debug logs ,PCAP and JMX where we have tested > with version 9.0.56 here : > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444 > 5555731-d40684d89713d0eb&q=1&e=8a27bb36-1eab-4d6a-bee6-03760f68d928&u= > https%3A%2F%2Fdrive.google.com%2Ffile%2Fd%2F1u4Sc_7oSB9tdJN8ls9xTMrRqP > 8IFoACM%2Fview%3Fusp%3Dsharing > > The same JMX works fine with the overhead values changed to zero. Which indicates the requests you are sending are triggering the excessive overhead protection code. > Will we have any side effects on changing the overhead parameters to zero? For Tomcat, generally not since it wasn't vulnerable to the various HTTP/2 DoS attacks that were popular a few years ago. The overhead protection was added primarily as a way to detect and reject clients exhibiting abusive behaviour. Looking at your source code you have set the HTTP/2 initial window size to 500. That is far too low. Since it is lower than the default overhead threshold for data (1024) it means every single DATA frame is going to be classed as abusive. No wonder the connection gets closed down so quickly. If you set the default window size to something sensible - or just leave it as the default - do you still see the issue? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
