On Wed, 10 Dec 2025 16:37:15 GMT, Daniel Fuchs <[email protected]> wrote:
>> Right, we only create one connection initially, and requests 2 and 3 are >> usually sent over the first connection before they are retried on new >> connections. This can be observed in the server logs as `resetting stream 3 >> as REFUSED_STREAM`. Ideally the server should not send anything after >> sending the GOAWAY frame with error, but I think what we have is good enough, > >> @djelinski Oops, you're right! I moved `goAwaySentLatch.await()` back to its >> original position and now it works as expected - only 1 connection is >> created initially, and the other 2 are retries. Tested locally and all >> passed. > > FWIW - if the request succeeds (no exception thrown) you can check/assert > whether two requests were sent on the same or different connections by > comparing the value returned by `HttpResponse::connectionLabel()`; Though the > result is an `Optional` our implementation will never return an empty > optional. @dfuch Thank you for the thorough review. I've applied `Utils.adjustTimeout()` to both timeout values as you suggested. Also, thanks for the tip about `HttpResponse::connectionLabel()` - that's really helpful to know for verifying connection reuse in the future. For this test, I'll keep the current approach since it's already validating the retry behavior correctly, but I'll definitely keep that in mind for future tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3639363834
