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

[robert engels]

On Mon, 22 Apr 2024 12:16:14 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   flush after exchange returns
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 851:
> 
>> 849:                     uc.doFilter (new HttpExchangeImpl (tx));
>> 850:                 }
>> 851:                 tx.getResponseBody().flush();
> 
> I admire the creativity, but I don't think we can do that here. At this point the stream can be owned by another thread, either because the response was completed and we are now handling another request, or because the user decided to handle the request on a separate thread started from `handle`. In either case, flushing here could lead to concurrency issues like sending the wrong data to the user.

I reverted the commit. I think my comment that the TcpNoDelayNotRequired hangs the client connection if the stream is not closed - in the existing JDK code - shows that the concern regarding "existing code" is not valid. I think it only these test cases that exhibit the bad behavior and it was never detected because the tests are run in isolation in a new jvm each time.

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

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