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

[robert engels]

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

>> 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.
>
> We don't want to allow it; we want to fix the broken tests, and add a release note so that the users know how to recognize that their code is broken and know how to fix it. 
> 
> This should be fine in a new JDK version, where the users are expected to invest some effort in upgrading. Do you plan to backport this change to older releases? If you do, it would make sense to add a system property to revert to the old (slow) behavior. This would allow the users to use the updated version without recompiling their code.

also, I reviewed the semantics of the buffered output stream. It is fully synchronized, so flushing here is fine and cannot corrupt the data to the client. But still, I don't think it is needed as it doesn't really solve anything if the api conditions are more clearly specified.

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

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