@@ -314,7 +314,9 @@ public void performanceChunked(String scheme) throws Exception {
314314
315315 int iterations = 15_000 ;
316316 CountingInstrumenter instrumenter = new CountingInstrumenter ();
317- try (var client = makeClient (scheme , null ); var ignore = makeServer (scheme , handler , instrumenter ).start ()) {
317+ try (var client = makeClient (scheme , null ); var ignore = makeServer (scheme , handler , instrumenter )
318+ // Note default max requests per connection is 100k, so we shouldn't be closing the connections based upon the total requests.
319+ .start ()) {
318320 URI uri = makeURI (scheme , "" );
319321 long start = System .currentTimeMillis ();
320322 long lastLog = start ;
@@ -364,6 +366,12 @@ public void performanceChunked(String scheme) throws Exception {
364366 }
365367
366368 // We are using keep-alive, so expect 1 connection, and the total requests accepted, and chunked responses should equal the iteration count.
369+ // - This assertion does seem to fail every once in a while, and it will be 2 instead of 1. My guess is that this is ok - we don't always know
370+ // how an HTTP client is going to work, and it may decide to cycle a connection even if the server didn't force it. We are using the JDK
371+ // REST client which does seem to be fairly predictable, but for example, using a REST client that uses HttpURLConnection is much less
372+ // predictable, but fast. 😀
373+ //
374+ // If it keeps failing, we could modify this assertion to assert 1 or 2.
367375 assertEquals (instrumenter .getConnections (), 1 );
368376 assertEquals (instrumenter .getChunkedResponses (), iterations );
369377 assertEquals (instrumenter .getAcceptedRequests (), iterations );
0 commit comments