On Fri, 19 Apr 2024 08:53:13 GMT, Daniel Jeliński <djelin...@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
