On Tue, 12 Nov 2024 19:43:45 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> [JDK-8342075](https://bugs.openjdk.org/browse/JDK-8342075) has introduced >> more flow controls checks, but also introduced a race condition where >> DataFrames for closed streams may fail to be discounted from the connection >> window. >> >> The consequence is that WINDOW_UPDATE frames for the connection window may >> not be sent when they should, preventing the server from making progress and >> stalling the connection. >> >> This can be shown by modifying the StreamFlowControlTest to send less but >> bigger frames (e.g. chunks of 1600 bytes instead of chunks of 12 bytes). >> With such a modification the test can be seen failing intermittently, when >> sameClient=true. >> >> The race happens when frames that have been added to Stream::inputQ fail to >> be drained after the stream is closed (or continue to be added to the inputQ >> after the stream is closed). >> >> The fix ensures that Stream::drainInputQueue() is called when the stream is >> closed, and that no further data farme will be added to the inputQ after the >> stream is marked closed. >> >> The modified StreamFlowControlTest could be observed failing relatively >> frequently on linux-aarch64 without the fix. >> With the fix the test no longer fails. > > Daniel Fuchs has updated the pull request incrementally with one additional > commit since the last revision: > > Update test/jdk/java/net/httpclient/http2/StreamFlowControlTest.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1594: > 1592: Log.logError(ex); > 1593: } finally { > 1594: drainInputQueue(); Hello Daniel, now that the `cancelImpl(...)` itself drains the queue in a `finally` block, do you think we should remove the call to `drainInputQueue()` from the finally block of `schedule()` after we call `cancelImpl(...)` there? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21991#discussion_r1839922670
