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 am not sure the semantics of a flush on a stream chain that the server owns in subject to corruption in this way - as it should only be sending data waiting to be sent, but in general, you’re correct. 

Based on all of the feedback I don’t think this can be fixed if you want to allow existing incorrect behavior. 

I am under the impression that the stream or exchange must be closed - not doing so is a bad bug. 

I am going to revert this change under that assumption. 

I am not sure where you want to go next. The current implementation leads to really poor network utilization.

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

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