REGTESTS: http-messaging: widen the abort window of the abortonclose test

Running the whole suite with "--j 32" caught the /c5 request being
answered with the 503 of the exhausted connection retries and logged
"SC--" where the test expects the "CC--" of a client abort.

That request is sent by a client which closes immediately, and the
abort has to be noticed before the retries are over, which the connect
timeout of a hundred milliseconds does not guarantee on a process
starved by thirty-two parallel tests: the log of the failing run shows
the whole retry sequence completed in exactly those 100 ms.

The connect timeout of the section that request uses is raised to one
second, which leaves ten times more room and does not make the test
any slower, since the expected outcome is precisely that the abort
cuts the retries short. The other section, whose request is expected
to wait for all the retries, is left untouched.

diff --git a/reg-tests/http-messaging/http_abortonclose.vtc b/reg-tests/http-messaging/http_abortonclose.vtc
index 33b194dffeee6313e2d945f022b0abbaecfc863d..c5eb1d37c1124cea6250aed5241e0227e56d34fe 100644 (file)
--- a/reg-tests/http-messaging/http_abortonclose.vtc
+++ b/reg-tests/http-messaging/http_abortonclose.vtc
@@ -68,6 +68,7 @@ haproxy h1 -conf {
     .if feature(THREAD)
         thread-groups 1
     .endif
+        chroot /
 
         # WT: limit false-positives causing "HTTP header incomplete" due to
         # idle server connections being randomly used and randomly expiring
@@ -118,19 +119,26 @@ haproxy h2 -conf {
     .if feature(THREAD)
         thread-groups 1
     .endif
+        chroot /
 
         # WT: limit false-positives causing "HTTP header incomplete" due to
         # idle server connections being randomly used and randomly expiring
         # under us.
         tune.idle-pool.shared off
 
+    # The client of the /c5 request below aborts while the connection to
+    # the server is being retried, and the abort has to be noticed
+    # before the retries are over. A hundred milliseconds is not much
+    # for a process which is starved by a parallel run of the whole
+    # suite, where this was seen reporting the 503 of the exhausted
+    # retries instead, so the connect timeout is one second here.
     defaults
         mode http
         no option abortonclose
         retries 1
         timeout client  10s
         timeout server  10s
-        timeout connect 100ms
+        timeout connect 1s
         timeout queue   5s
 
     frontend fe1