RFR: 6968351: httpserver clashes with delayed TCP ACKs for low Content-Length

[Daniel Fuchs]

On Fri, 19 Apr 2024 08:53:13 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 75:
> 
>> 73:         long time = System.currentTimeMillis()-start;
>> 74:         System.out.println("time "+time);
>> 75:         if(time>5000) throw new IllegalStateException("took too long");
> 
> Use jtreg timeout instead, like:
> 
> @run main/timeout=5 B6968351
> 
> (the timeout value is in seconds, but it's scaled x4 by default)
> 
> this will interrupt the test if/when the timeout is hit, and will also enable scaling the timeout on slower machines

Another possibility is to use Utils.adjustTimeout to take care of slow machines.

> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 91:
> 
>> 89:             rmap.add("content-type","text/plain");
>> 90:             t.sendResponseHeaders(200,5);
>> 91:             t.getResponseBody().write("hello".getBytes());
> 
> Suggestion:
> 
>             t.getResponseBody().write("hello".getBytes(StandardCharsets.ISO_8859_1));

well if you do that then you'd have to do 


t.sendResponseHeaders(200, "hello".getBytes(StandardCharsets.ISO_8859_1).length);


as well.... Or you could assume  that "hello" will always be encoded the same - and with 5 bytes,  whatever the charset...
There are quite a few tests that already make that assumption.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572148877
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572177151