On Mon, 22 Apr 2024 12:45:01 GMT, Daniel Jeliński <djelin...@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
