On 12/27/2025 23:54, Ryan Schmitt wrote:
I figured it out. It's a bug in the actual code, not the test. The code
checks for response data on non-SSL connections by calling
`inputStream.available()`, as originally suggested here:
https://www.mail-archive.com/[email protected]/msg09913.html
Unfortunately, `InputStream::available` only returns an *estimate*; the
contract for the method is basically that an attempt to read or skip
`available()` bytes will not trigger blocking behavior. The inverse is not
true: `available() == 0` does not imply that there is no data to be read,
and in fact `return 0` is a legal and common implementation of
`available()`.
Apparently, on some Java versions, on some operating systems, on some test
runs, the server's response never shows up as available() bytes. This
behavior is non-deterministic, but easily reproduced with `@RepeatedTest`:
I see `available()` repeatedly returning 0, but a subsequent call to
`connection.isDataAvailable(Timeout.ONE_MILLISECOND)` shows that data is in
fact available to be read. (This is very similar to the problem of
implementing validateAfterInactivity in the classic client, but complicated
by some very inconvenient non-determinism.) I went to considerable lengths
to confirm that this is not just a race condition in our code; it's some
sort of quirk of Java sockets, and/or the underlying OS.
Since this is an opt-in feature for users who presumably are willing to
take the documented performance hit in exchange for improved correctness,
I'm going to change the code to always perform a blocking read in order to
check for response data.
Thank you so much, Ryan, for looking into the problem and fixing it.
I imagine we should cherry-pick the MonitoringResponseOutOfOrderStrategy
related changes to 5.4.x as well.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
