Hi Daniel, I think I have a solution that would work. I will try to get a PR together. Do you know if there is an existing test case the demonstrates the issue? - if not, I will start with that.
Robert > On Apr 4, 2024, at 9:44 AM, Daniel Jeliński <djelins...@gmail.com> wrote: > > Hi Robert, > Thanks for bringing this up! We are aware of the issue, it's tracked under > https://bugs.openjdk.org/browse/JDK-6968351. > > If you have an idea for a proper fix that doesn't add too much complexity, > please open a PR, and we'll be happy to help. > Cheers, > Daniel > > czw., 4 kwi 2024, 14:55 użytkownik Robert Engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> napisał: >> >> When doing some testing on github.com/robaho/httpserver >> <http://github.com/robaho/httpserver> - which is a fork of the jdk http >> server, I discovered a significant performance issue. >> >> When an http connection is in ‘keep-alive’ - the default for http 1.1 - the >> headers are “flushed” here >> https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L281 >> >> This means that after the handler runs and it sends data - e.g. /hello sends >> “hello” on the connection, the connection will stall due to the Nagel >> algorithm - usually incurring a 50 ms delay. The stall occurs since the >> client will not see the expected data until after the delay, so it is unable >> to send the next (when reusing the same connection/HttpClient). >> >> You can set the TCP_NODELAY on the server to work-around this, but a better >> solution would be to override the flush() on the BufferedOutputStream to not >> flush() the underlying connection - i.e. only write the buffered bytes, or >> rework it a bit to only flush when there is no content to send. >>
