@@ -314,7 +314,9 @@ public void performanceChunked(String scheme) throws Exception {
314
314
315
315
int iterations = 15_000 ;
316
316
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 ()) {
318
320
URI uri = makeURI (scheme , "" );
319
321
long start = System .currentTimeMillis ();
320
322
long lastLog = start ;
@@ -364,6 +366,12 @@ public void performanceChunked(String scheme) throws Exception {
364
366
}
365
367
366
368
// 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.
367
375
assertEquals (instrumenter .getConnections (), 1 );
368
376
assertEquals (instrumenter .getChunkedResponses (), iterations );
369
377
assertEquals (instrumenter .getAcceptedRequests (), iterations );
0 commit comments