@@ -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