Re: regtests - with option http-use-htx
On 1/8/19 9:05 PM, PiBa-NL wrote: Hi Frederic, Op 8-1-2019 om 16:27 schreef Frederic Lecaille: On 12/15/18 4:52 PM, PiBa-NL wrote: Hi List, Willy, Trying to run some existing regtests with added option: option http-use-htx Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15 I get the below issues sofar: based on /reg-tests/connection/b0.vtc Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 expectation for syslog. This surely needs a closer look? # top TEST ./htx-test/connection-b0.vtc passed (8.490) based on /reg-tests/stick-table/b1.vtc Difference here is the use=1 vs use=0 , maybe that is better, but then the 'old' expectation seems wrong, and the bug is the case without htx? Note that the server s1 never responds. Furthermore, c1 client is run with -run argument. This means that we wait for its termination before running accessing CLI. Then we check that there is no consistency issue with the stick-table: if the entry has expired we get only this line: table: http1, type: ip, size:1024, used:0 if not we get these two lines: table: http1, type: ip, size:1024, used:1 .* use=0 ... here used=1 means there is still an entry in the stick-table, and use=0 means it is not currently in use (I guess this is because the client has closed its connection). I do not reproduce your issue with this script both on Linux and FreeBSD 11 both with or without htx. Did you try with the 'old' development version (1.9-dev10-c11ec4a 2018/12/15), i think in current version its already fixed see my own test results also below. No. I have not tested with the previous dev versions. I wanted to clarify the logic behind the test. I agree perhaps there is not enough comments in this script. h1 0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0 h1 0.0 CLI recv| h1 0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$" Regards, PiBa-NL (Pieter) I tried again today with both 2.0-dev0-251a6b7 and 1.9.0-8223050 and 1.9-dev10-c11ec4a : HA-Proxy version 2.0-dev0-251a6b7 2019/01/08 - https://haproxy.org/ ## Without HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127) 0 tests failed, 0 tests skipped, 2 tests passed ## With HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.147) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127) 0 tests failed, 0 tests skipped, 2 tests passed HA-Proxy version 1.9.0-8223050 2018/12/19 - https://haproxy.org/ ## Without HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.150) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.128) 0 tests failed, 0 tests skipped, 2 tests passed ## With HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.148) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127) 0 tests failed, 0 tests skipped, 2 tests passed Ok. HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15 Copyright 2000-2018 Willy Tarreau ## Without HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127) 0 tests failed, 0 tests skipped, 2 tests passed ## With HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (8.646) * top 0.0 TEST ./PB-TEST/2018/stick-table-b1.vtc starting h1 0.0 CLI recv|# table: http1, type: ip, size:1024, used:1 h1 0.0 CLI recv|0x80262a200: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0 h1 0.0 CLI recv| h1 0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$" * top 0.0 RESETTING after ./PB-TEST/2018/stick-table-b1.vtc ** h1 0.0 Reset and free h1 haproxy 92940 # top TEST ./PB-TEST/2018/stick-table-b1.vtc FAILED (0.127) exit=2 1 tests failed, 0 tests skipped, 1 tests passed With the 'old' 1.9-dev10 version and with HTX i can still reproduce the "passed (8.646)" and "use=1".. But both 1.9.0 and 2.0-dev don't show that behavior. I have not 'bisected' further, but i don't think there is anything to do a.t.m. regarding this old (already fixed) issue. Good news. Thanks Pieter. Regards, PiBa-NL (Pieter) Regards. Fred
Re: regtests - with option http-use-htx
Hi Frederic, Op 8-1-2019 om 16:27 schreef Frederic Lecaille: On 12/15/18 4:52 PM, PiBa-NL wrote: Hi List, Willy, Trying to run some existing regtests with added option: option http-use-htx Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15 I get the below issues sofar: based on /reg-tests/connection/b0.vtc Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 expectation for syslog. This surely needs a closer look? # top TEST ./htx-test/connection-b0.vtc passed (8.490) based on /reg-tests/stick-table/b1.vtc Difference here is the use=1 vs use=0 , maybe that is better, but then the 'old' expectation seems wrong, and the bug is the case without htx? Note that the server s1 never responds. Furthermore, c1 client is run with -run argument. This means that we wait for its termination before running accessing CLI. Then we check that there is no consistency issue with the stick-table: if the entry has expired we get only this line: table: http1, type: ip, size:1024, used:0 if not we get these two lines: table: http1, type: ip, size:1024, used:1 .* use=0 ... here used=1 means there is still an entry in the stick-table, and use=0 means it is not currently in use (I guess this is because the client has closed its connection). I do not reproduce your issue with this script both on Linux and FreeBSD 11 both with or without htx. Did you try with the 'old' development version (1.9-dev10-c11ec4a 2018/12/15), i think in current version its already fixed see my own test results also below. h1 0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0 h1 0.0 CLI recv| h1 0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$" Regards, PiBa-NL (Pieter) I tried again today with both 2.0-dev0-251a6b7 and 1.9.0-8223050 and 1.9-dev10-c11ec4a : HA-Proxy version 2.0-dev0-251a6b7 2019/01/08 - https://haproxy.org/ ## Without HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127) 0 tests failed, 0 tests skipped, 2 tests passed ## With HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.147) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127) 0 tests failed, 0 tests skipped, 2 tests passed HA-Proxy version 1.9.0-8223050 2018/12/19 - https://haproxy.org/ ## Without HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.150) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.128) 0 tests failed, 0 tests skipped, 2 tests passed ## With HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.148) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127) 0 tests failed, 0 tests skipped, 2 tests passed HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15 Copyright 2000-2018 Willy Tarreau ## Without HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146) # top TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127) 0 tests failed, 0 tests skipped, 2 tests passed ## With HTX # top TEST ./PB-TEST/2018/connection-b0.vtc passed (8.646) * top 0.0 TEST ./PB-TEST/2018/stick-table-b1.vtc starting h1 0.0 CLI recv|# table: http1, type: ip, size:1024, used:1 h1 0.0 CLI recv|0x80262a200: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0 h1 0.0 CLI recv| h1 0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$" * top 0.0 RESETTING after ./PB-TEST/2018/stick-table-b1.vtc ** h1 0.0 Reset and free h1 haproxy 92940 # top TEST ./PB-TEST/2018/stick-table-b1.vtc FAILED (0.127) exit=2 1 tests failed, 0 tests skipped, 1 tests passed With the 'old' 1.9-dev10 version and with HTX i can still reproduce the "passed (8.646)" and "use=1".. But both 1.9.0 and 2.0-dev don't show that behavior. I have not 'bisected' further, but i don't think there is anything to do a.t.m. regarding this old (already fixed) issue. Regards, PiBa-NL (Pieter)
Re: regtests - with option http-use-htx
On 12/15/18 4:52 PM, PiBa-NL wrote: Hi List, Willy, Trying to run some existing regtests with added option: option http-use-htx Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15 I get the below issues sofar: based on /reg-tests/connection/b0.vtc Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 expectation for syslog. This surely needs a closer look? # top TEST ./htx-test/connection-b0.vtc passed (8.490) based on /reg-tests/stick-table/b1.vtc Difference here is the use=1 vs use=0 , maybe that is better, but then the 'old' expectation seems wrong, and the bug is the case without htx? Note that the server s1 never responds. Furthermore, c1 client is run with -run argument. This means that we wait for its termination before running accessing CLI. Then we check that there is no consistency issue with the stick-table: if the entry has expired we get only this line: table: http1, type: ip, size:1024, used:0 if not we get these two lines: table: http1, type: ip, size:1024, used:1 .*use=0 ... here used=1 means there is still an entry in the stick-table, and use=0 means it is not currently in use (I guess this is because the client has closed its connection). I do not reproduce your issue with this script both on Linux and FreeBSD 11 both with or without htx. h1 0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0 h1 0.0 CLI recv| h1 0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$" Regards, PiBa-NL (Pieter)
Re: regtests - with option http-use-htx
On Sat, Dec 15, 2018 at 05:18:08PM +0100, PiBa-NL wrote: > > > h1 0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 > > > gpc0=0 > > > gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 > > > http_req_rate(1)=1 > > > http_err_cnt=0 http_err_rate(1)=0 > > > h1 0.0 CLI recv| > > > h1 0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, > > > used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 > > > gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 > > > http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$" > > Hmmm here I think we're really hitting corner cases depending on whether > > the tracked counters are released before or after the logs are emitted. > > In the case of htx, the logs are emitted slightly later than before, > > which may induce this. Quite honestly I'd be inclined to set use=[01] > > here in the regex to cover the race condition that exists in both cases, > > as there isn't any single good value. Christopher, are you also OK with > > this ? I can do the patch if you're OK. > Its not about emitting logs, its querying the stats admin socket, Ah of course you're right, I recognize the output now! > and even > with a added 'delay 2' before doing so the results seem to show the same > difference with/without htx. I don't think its a matter of 'timing' .? I still don't know well. Without htx, the stream is created when the connection is accepted and maintained till its end, so it may very well hold a reference to the table entry even while the connection is idle waiting for a new request. With HTX, it's like with H2, the stream only lives for the time it takes to perform a request/response. I think that using barriers to get the output after the request is sent but before the server starts to respond could reveal the use=1 here. But apparently it's the barrier in the "haproxy-cli" section of varnishtest that makes it crash so it might not be the easiest thing to try for now. Maybe you can try placing the delay between the rxreq and txresp statements in the server section and try to make sure your CLI access happens in the middle :-/ Thanks, Willy
Re: regtests - with option http-use-htx
Hi Willy, Op 15-12-2018 om 17:06 schreef Willy Tarreau: Hi Pieter, On Sat, Dec 15, 2018 at 04:52:10PM +0100, PiBa-NL wrote: Hi List, Willy, Trying to run some existing regtests with added option: option http-use-htx Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15 I get the below issues sofar: based on /reg-tests/connection/b0.vtc Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 expectation for syslog. This surely needs a closer look? # top TEST ./htx-test/connection-b0.vtc passed (8.490) It looks exactly like another issue we've found when a content-length is missing but the close is not seen, which is the same in your case with the first proxy returning the 503 error page by default. Christopher told me he understands what's happening in this situation (at least for the one we've met), I'm CCing him in case this report fuels this thoughts. Ok thanks. based on /reg-tests/stick-table/b1.vtc Difference here is the use=1 vs use=0 , maybe that is better, but then the 'old' expectation seems wrong, and the bug is the case without htx? h1 0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0 h1 0.0 CLI recv| h1 0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$" Hmmm here I think we're really hitting corner cases depending on whether the tracked counters are released before or after the logs are emitted. In the case of htx, the logs are emitted slightly later than before, which may induce this. Quite honestly I'd be inclined to set use=[01] here in the regex to cover the race condition that exists in both cases, as there isn't any single good value. Christopher, are you also OK with this ? I can do the patch if you're OK. Its not about emitting logs, its querying the stats admin socket, and even with a added 'delay 2' before doing so the results seem to show the same difference with/without htx. I don't think its a matter of 'timing' .? Regards, PiBa-NL (Pieter) ** c1 0.0 === expect resp.status == 503 c1 0.0 EXPECT resp.status (503) == "503" match *** c1 0.0 closing fd 7 ** c1 0.0 Ending ** top 0.0 === delay 2 *** top 0.0 delaying 2 second(s) ** top 2.1 === haproxy h1 -cli { ** h1 2.1 CLI starting ** h1 2.1 CLI waiting *** h1 2.1 CLI connected fd 7 from ::1 26202 to ::1 26153 ** h1 2.1 === send "show table http1" h1 2.1 CLI send|show table http1 ** h1 2.1 === expect ~ "table: http1, type: ip, size:1024, used:(0|1\\n0x[... *** h1 2.1 debug|0001:GLOBAL.accept(0005)=000b from [::1:26202] ALPN= h1 2.1 CLI connection normally closed *** h1 2.1 CLI closing fd 7 *** h1 2.1 debug|0001:GLOBAL.srvcls[adfd:] *** h1 2.1 debug|0001:GLOBAL.clicls[adfd:] *** h1 2.1 debug|0001:GLOBAL.closed[adfd:] h1 2.1 CLI recv|# table: http1, type: ip, size:1024, used:1 h1 2.1 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0 h1 2.1 CLI recv| h1 2.1 CLI expect failed ~ "table: http1, type: ip, size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"
Re: regtests - with option http-use-htx
Hi Pieter, On Sat, Dec 15, 2018 at 04:52:10PM +0100, PiBa-NL wrote: > Hi List, Willy, > > Trying to run some existing regtests with added option: option http-use-htx > > Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15 > > I get the below issues sofar: > > based on /reg-tests/connection/b0.vtc > Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 expectation > for syslog. This surely needs a closer look? > # top TEST ./htx-test/connection-b0.vtc passed (8.490) It looks exactly like another issue we've found when a content-length is missing but the close is not seen, which is the same in your case with the first proxy returning the 503 error page by default. Christopher told me he understands what's happening in this situation (at least for the one we've met), I'm CCing him in case this report fuels this thoughts. > based on /reg-tests/stick-table/b1.vtc > Difference here is the use=1 vs use=0 , maybe that is better, but then the > 'old' expectation seems wrong, and the bug is the case without htx? > > h1 0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0 > gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1 > http_err_cnt=0 http_err_rate(1)=0 > h1 0.0 CLI recv| > h1 0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, > used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 > gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 > http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$" Hmmm here I think we're really hitting corner cases depending on whether the tracked counters are released before or after the logs are emitted. In the case of htx, the logs are emitted slightly later than before, which may induce this. Quite honestly I'd be inclined to set use=[01] here in the regex to cover the race condition that exists in both cases, as there isn't any single good value. Christopher, are you also OK with this ? I can do the patch if you're OK. > Regards, > > PiBa-NL (Pieter) > Thanks, Willy > #commit b406b87 > # BUG/MEDIUM: connection: don't store recv() result into trash.data > # > # Cyril Bonté discovered that the proxy protocol randomly fails since > # commit 843b7cb ("MEDIUM: chunks: make the chunk struct's fields match > # the buffer struct"). This is because we used to store recv()'s return > # code into trash.data which is now unsigned, so it never compares as > # negative against 0. Let's clean this up and test the result itself > # without storing it first. > > varnishtest "PROXY protocol random failures" > > feature ignore_unknown_macro > > syslog Slog_1 -repeat 8 -level info { > recv > expect ~ "Connect from .* to ${h1_ssl_addr}:${h1_ssl_port}" > recv > expect ~ "ssl-offload-http/http .* \"POST /[1-8] HTTP/2\\.0\"" > } -start > > haproxy h1 -conf { > global > nbproc 4 > nbthread 4 > tune.ssl.default-dh-param 2048 > stats bind-process 1 > log ${Slog_1_addr}:${Slog_1_port} len 2048 local0 debug err > > defaults > mode http > timeout client 1s > timeout server 1s > timeout connect 1s > log global > > option http-use-htx > > listen http > bind-process 1 > bind unix@${tmpdir}/http.socket accept-proxy name ssl-offload-http > option forwardfor > > listen ssl-offload-http > option httplog > bind-process 2-4 > bind "fd@${ssl}" ssl crt ${testdir}/common.pem ssl no-sslv3 alpn > h2,http/1.1 > server http unix@${tmpdir}/http.socket send-proxy > } -start > > > shell { > HOST=${h1_ssl_addr} > if [ "$HOST" = "::1" ] ; then > HOST="\[::1\]" > fi > for i in 1 2 3 4 5 6 7 8 ; do > urls="$urls https://$HOST:${h1_ssl_port}/$i"; > done > curl -i -k -d 'x=x' $urls & wait $! > } > > syslog Slog_1 -wait > # commit 3e60b11 > # BUG/MEDIUM: stick-tables: Decrement ref_cnt in table_* converters > # > # When using table_* converters ref_cnt was incremented > # and never decremented causing entries to not expire. > # > # The root cause appears to be that stktable_lookup_key() > # was called within all sample_conv_table_* functions which was > # incrementing ref_cnt and not decrementing after completion. > # > # Added stktable_release() to the end of each sample_conv_table_* > # function and reworked the end logic to ensure that ref_cnt is > # always decremented after use. > # > # This should be backported to 1.8 > > varnishtest "stick-tables: Test expirations when used with table_*" > > # As some macros for haproxy are used in this file, this line is mandatory. > feature ignore_unknown_macro > > # Do nothing. > server s1 { > } -start > > haproxy h1 -conf { > # Configuration file of 'h1' haproxy instance. > defaults > mode http > timeout connect 5s > timeout server 30s > timeout client
regtests - with option http-use-htx
Hi List, Willy, Trying to run some existing regtests with added option: option http-use-htx Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15 I get the below issues sofar: based on /reg-tests/connection/b0.vtc Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 expectation for syslog. This surely needs a closer look? # top TEST ./htx-test/connection-b0.vtc passed (8.490) based on /reg-tests/stick-table/b1.vtc Difference here is the use=1 vs use=0 , maybe that is better, but then the 'old' expectation seems wrong, and the bug is the case without htx? h1 0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0 h1 0.0 CLI recv| h1 0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$" Regards, PiBa-NL (Pieter) #commit b406b87 # BUG/MEDIUM: connection: don't store recv() result into trash.data # # Cyril Bonté discovered that the proxy protocol randomly fails since # commit 843b7cb ("MEDIUM: chunks: make the chunk struct's fields match # the buffer struct"). This is because we used to store recv()'s return # code into trash.data which is now unsigned, so it never compares as # negative against 0. Let's clean this up and test the result itself # without storing it first. varnishtest "PROXY protocol random failures" feature ignore_unknown_macro syslog Slog_1 -repeat 8 -level info { recv expect ~ "Connect from .* to ${h1_ssl_addr}:${h1_ssl_port}" recv expect ~ "ssl-offload-http/http .* \"POST /[1-8] HTTP/2\\.0\"" } -start haproxy h1 -conf { global nbproc 4 nbthread 4 tune.ssl.default-dh-param 2048 stats bind-process 1 log ${Slog_1_addr}:${Slog_1_port} len 2048 local0 debug err defaults mode http timeout client 1s timeout server 1s timeout connect 1s log global option http-use-htx listen http bind-process 1 bind unix@${tmpdir}/http.socket accept-proxy name ssl-offload-http option forwardfor listen ssl-offload-http option httplog bind-process 2-4 bind "fd@${ssl}" ssl crt ${testdir}/common.pem ssl no-sslv3 alpn h2,http/1.1 server http unix@${tmpdir}/http.socket send-proxy } -start shell { HOST=${h1_ssl_addr} if [ "$HOST" = "::1" ] ; then HOST="\[::1\]" fi for i in 1 2 3 4 5 6 7 8 ; do urls="$urls https://$HOST:${h1_ssl_port}/$i"; done curl -i -k -d 'x=x' $urls & wait $! } syslog Slog_1 -wait # commit 3e60b11 # BUG/MEDIUM: stick-tables: Decrement ref_cnt in table_* converters # # When using table_* converters ref_cnt was incremented # and never decremented causing entries to not expire. # # The root cause appears to be that stktable_lookup_key() # was called within all sample_conv_table_* functions which was # incrementing ref_cnt and not decrementing after completion. # # Added stktable_release() to the end of each sample_conv_table_* # function and reworked the end logic to ensure that ref_cnt is # always decremented after use. # # This should be backported to 1.8 varnishtest "stick-tables: Test expirations when used with table_*" # As some macros for haproxy are used in this file, this line is mandatory. feature ignore_unknown_macro # Do nothing. server s1 { } -start haproxy h1 -conf { # Configuration file of 'h1' haproxy instance. defaults mode http timeout connect 5s timeout server 30s timeout client 30s option http-use-htx frontend http1 bind "fd@${my_frontend_fd}" stick-table size 1k expire 1ms type ip store conn_rate(10s),http_req_cnt,http_err_cnt,http_req_rate(10s),http_err_rate(10s),gpc0,gpc0_rate(10s),gpt0 http-request track-sc0 req.hdr(X-Forwarded-For) http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_http_req_cnt(http1) -m int lt 0 } http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_trackers(http1) -m int lt 0 } http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),in_table(http1) -m int lt 0 } http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_bytes_in_rate(http1) -m int lt 0 } http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_bytes_out_rate(http1) -m int lt 0 } http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_conn_cnt(http1) -m int lt 0 } http