Recently on AIX the same change was needed to address the test time outs
in the
test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java test
- https://github.com/openjdk/jdk/pull/17363
-Jaikiran
On 08/04/24 1:50 pm, Daniel Jeliński wrote:
Hi Robert,
If you are on Linux, see test/jdk/java/net/vthread/HttpALot.java. That
test was recently modified to add -Dsun.net.httpserver.nodelay=true
[1], because it took forever to complete on LInux machines. On other
OSes the problem is not visible in existing tests.
Cheers,
Daniel
[1] https://github.com/openjdk/jdk/pull/10504
sob., 6 kwi 2024 o 00:37 robert engels <reng...@ix.netcom.com> napisał(a):
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>
napisał:
When doing some testing on 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.
