REGTESTS: log: serve the transaction state test on a single connection

Running the whole suite with "--j 32" caught the client of this test
receiving a close instead of the response to its second request. The
server was answering each of the four requests in its own iteration,
so it closed its connection after every response, and the debug trace
of the failing run shows the close reaching haproxy just as the next
request was sent over the connection it had reused:

    00000000:be.srvrep[003b:003a]: HTTP/1.1 200 OK
    00000000:be.srvcls[003b:003a]
    00000001:fe.clireq[003b:ffffffff]: GET /err HTTP/1.1
    00000001:be.srvcls[003b:003a]
    00000001:be.clicls[003b:003a]

The four requests are now served on a single connection, which is what
a keep-alive server does, so nothing closes in the middle of the
client's series. Twenty-four runs in parallel with the machine loaded
pass where the previous version failed twice out of sixteen.

diff --git a/reg-tests/log/txn_state.vtc b/reg-tests/log/txn_state.vtc
index b9f42824be0557cb355f404e04598c36a91c8710..80d93eee0ba698ed159f36f4f9831076f75ea7e6 100644 (file)
--- a/reg-tests/log/txn_state.vtc
+++ b/reg-tests/log/txn_state.vtc
@@ -14,10 +14,25 @@ varnishtest "Test the transaction state fetches and the logging actions"
 
 feature ignore_unknown_macro
 
+# The four requests which reach the server are served on a single
+# connection. A server closing after each response would close it just
+# as the client sends its next request over the same connection, which
+# haproxy reuses, and the client then gets a close instead of a
+# response. That made this test fail when the whole suite runs with
+# "--j 32".
 server s1 {
        rxreq
        txresp
-} -repeat 4 -start
+
+       rxreq
+       txresp
+
+       rxreq
+       txresp
+
+       rxreq
+       txresp
+} -start
 
 # vtest's syslog server only matches the messages emitted at its own
 # level, so two of them are needed to observe the effect of