RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/reg-tests/http-messaging/http_abortonclose.vtc

140 lines
3.4 KiB
Plaintext
Raw Normal View History

REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
varnishtest "A test for the abortonclose option (H1 only)"
feature ignore_unknown_macro
# NOTE : This test may fail if too many vtest are running in parallel because
# the port reserved for closed s1 server may be reused by another vtest
REGTESTS: Replace REQUIRE_VERSION=2.5 with 'haproxy -cc' This is safe, because running `haproxy -cc 'version_atleast(2.5-dev0)'` on HAProxy 2.4 will also result in an exit code of 1.
2021-06-11 17:56:15 +00:00
feature cmd "$HAPROXY_PROGRAM -cc 'version_atleast(2.5-dev0)'"
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
#REGTEST_TYPE=slow
REGTESTS: abortonclose: Fix some race conditions Depending on the timing, the second client that should be reported as a client abort during connection attempt ("CC--" termination state) is sometime logged as a server close ("SC--" termination state) instead. It happens because sometime the connection failure to the server s1 is detected by haproxy before the client c2 aborts. There is no retries and the connection timeout is set to 100ms. So, to work, the client abort must be performed and detected by haproxy in less than 100ms. To fix the issue, the c2 client is now routed to a backend with a connection timeout set to 1 second and 10 retries. It should be large enough to detect the client aborts (~10s) In addition, there is another race condition when the script is started. sometime, server s1 is not stopped when the first client sends its request. So a barrier was added to be sure it is stopped before starting to send requests. And we wait to be sure the server is detected as DOWN to unblock the barrier. It is performed by a dedicated backend with an healthcheck on the server s1. This patch should solve issue #1664.
2022-05-17 13:08:22 +00:00
# b0 : Wait s1 was detected as DOWN to be sure it is stopped
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
# b1 : Don't send /c4 before /c3 was received by s2 server
# b2 : Don't finish c2 before c1 and c3 before c4 (from syslog POV)
# b3 : finish c3 before s2
REGTESTS: abortonclose: Fix some race conditions Depending on the timing, the second client that should be reported as a client abort during connection attempt ("CC--" termination state) is sometime logged as a server close ("SC--" termination state) instead. It happens because sometime the connection failure to the server s1 is detected by haproxy before the client c2 aborts. There is no retries and the connection timeout is set to 100ms. So, to work, the client abort must be performed and detected by haproxy in less than 100ms. To fix the issue, the c2 client is now routed to a backend with a connection timeout set to 1 second and 10 retries. It should be large enough to detect the client aborts (~10s) In addition, there is another race condition when the script is started. sometime, server s1 is not stopped when the first client sends its request. So a barrier was added to be sure it is stopped before starting to send requests. And we wait to be sure the server is detected as DOWN to unblock the barrier. It is performed by a dedicated backend with an healthcheck on the server s1. This patch should solve issue #1664.
2022-05-17 13:08:22 +00:00
barrier b0 cond 2 -cyclic
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
barrier b1 cond 2 -cyclic
barrier b2 cond 2 -cyclic
barrier b3 cond 2 -cyclic
server s1 {
} -start
server s1 -break
server s2 {
rxreq
# unlock c4
barrier b1 sync
# wait end of c3
barrier b3 sync
expect_close
} -start
syslog S -level info {
REGTESTS: abortonclose: Fix some race conditions Depending on the timing, the second client that should be reported as a client abort during connection attempt ("CC--" termination state) is sometime logged as a server close ("SC--" termination state) instead. It happens because sometime the connection failure to the server s1 is detected by haproxy before the client c2 aborts. There is no retries and the connection timeout is set to 100ms. So, to work, the client abort must be performed and detected by haproxy in less than 100ms. To fix the issue, the c2 client is now routed to a backend with a connection timeout set to 1 second and 10 retries. It should be large enough to detect the client aborts (~10s) In addition, there is another race condition when the script is started. sometime, server s1 is not stopped when the first client sends its request. So a barrier was added to be sure it is stopped before starting to send requests. And we wait to be sure the server is detected as DOWN to unblock the barrier. It is performed by a dedicated backend with an healthcheck on the server s1. This patch should solve issue #1664.
2022-05-17 13:08:22 +00:00
recv alert
expect ~ "[^:\\[ ]*\\[[0-9]*\\]: Server check/srv1 is DOWN.*"
barrier b0 sync
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
recv
REGTESTS: abortonclose: Fix some race conditions Depending on the timing, the second client that should be reported as a client abort during connection attempt ("CC--" termination state) is sometime logged as a server close ("SC--" termination state) instead. It happens because sometime the connection failure to the server s1 is detected by haproxy before the client c2 aborts. There is no retries and the connection timeout is set to 100ms. So, to work, the client abort must be performed and detected by haproxy in less than 100ms. To fix the issue, the c2 client is now routed to a backend with a connection timeout set to 1 second and 10 retries. It should be large enough to detect the client aborts (~10s) In addition, there is another race condition when the script is started. sometime, server s1 is not stopped when the first client sends its request. So a barrier was added to be sure it is stopped before starting to send requests. And we wait to be sure the server is detected as DOWN to unblock the barrier. It is performed by a dedicated backend with an healthcheck on the server s1. This patch should solve issue #1664.
2022-05-17 13:08:22 +00:00
expect ~ "[^:\\[ ]*\\[[0-9]*\\]: .* .* fe1 be1_1/srv1 [0-9]*/[0-9]*/-1/-1/[0-9]* 503 .* - - SC-- .* .* \"GET /c1 HTTP/1\\.1\""
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
barrier b2 sync
recv
REGTESTS: abortonclose: Fix some race conditions Depending on the timing, the second client that should be reported as a client abort during connection attempt ("CC--" termination state) is sometime logged as a server close ("SC--" termination state) instead. It happens because sometime the connection failure to the server s1 is detected by haproxy before the client c2 aborts. There is no retries and the connection timeout is set to 100ms. So, to work, the client abort must be performed and detected by haproxy in less than 100ms. To fix the issue, the c2 client is now routed to a backend with a connection timeout set to 1 second and 10 retries. It should be large enough to detect the client aborts (~10s) In addition, there is another race condition when the script is started. sometime, server s1 is not stopped when the first client sends its request. So a barrier was added to be sure it is stopped before starting to send requests. And we wait to be sure the server is detected as DOWN to unblock the barrier. It is performed by a dedicated backend with an healthcheck on the server s1. This patch should solve issue #1664.
2022-05-17 13:08:22 +00:00
expect ~ "[^:\\[ ]*\\[[0-9]*\\]: .* .* fe1 be1_2/srv1 [0-9]*/[0-9]*/-1/-1/[0-9]* -1 .* - - CC-- .* .* \"GET /c2 HTTP/1\\.1\""
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
recv
REGTESTS: Fix http_abortonclose.vtc to support -1 status for some client aborts Since the commit 5e702fcad ("MINOR: http-ana: Use -1 status for client aborts during queuing and connect"), -1 status is reported in the log message when the client aborts during queuing and connect. http_abortonclose.vtc script must be update accordingly.
2021-06-02 15:23:47 +00:00
expect ~ "[^:\\[ ]*\\[[0-9]*\\]: .* .* fe2 be2/<NOSRV> [0-9]*/[0-9]*/-1/-1/[0-9]* -1 .* - - CQ-- .* .* \"GET /c4 HTTP/1\\.1\""
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
barrier b2 sync
recv
expect ~ "[^:\\[ ]*\\[[0-9]*\\]: .* .* fe2 be2/srv1 [0-9]*/[0-9]*/[0-9]*/-1/[0-9]* 400 .* - - CH-- .* .* \"GET /c3 HTTP/1\\.1\""
} -start
haproxy h1 -conf {
REGTESTS: disable inter-thread idle connection sharing on sensitive tests Some regtests involve multiple requests from multiple clients, which can be dispatched as multiple requests to a server. It turns out that the idle connection sharing works so well that very quickly few connections are used, and regularly some of the remaining idle server connections time out at the moment they were going to be reused, causing those random "HTTP header incomplete" traces in the logs that make them fail often. In the end this is only an artefact of the test environment. And indeed, some tests like normalize-uri which perform a lot of reuse fail very often, about 20-30% of the times in the CI, and 100% of the time in local when running 1000 tests in a row. Others like ubase64, sample_fetches or vary_* fail less often but still a lot in tests. This patch addresses this by adding "tune.idle-pool.shared off" to all tests which have at least twice as many requests as clients. It proves very effective as no single error happens on normalize-uri anymore after 10000 tests. Also 100 full runs of all tests yield no error anymore. One test is tricky, http_abortonclose, it used to fail ~10 times per 1000 runs and with this workaround still fails once every 1000 runs. But the test is complex and there's a warning in it mentioning a possible issue when run in parallel due to a port reuse.
2021-05-09 12:41:41 +00:00
global
# 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
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
defaults
mode http
option abortonclose
REGTEST: set retries count to zero for all tests that expect at 503 Some tests expect a 503, typically those that check that wrong CA/CRL will not be accepted between a server and a frontend. But such tests tend to last very long simply because of the 1-second turn-around on connection retries that happens during the failure. Let's properly set the retries count to zero for these ones. One test purposely wants to exhaust the retries so the retries was set to 1 instead.
2021-11-18 16:15:59 +00:00
retries 1
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
timeout client 10s
timeout server 10s
timeout connect 100ms
timeout queue 5s
frontend fe1
option httplog
log ${S_addr}:${S_port} local0 debug err
bind "fd@${fe1}"
REGTESTS: abortonclose: Fix some race conditions Depending on the timing, the second client that should be reported as a client abort during connection attempt ("CC--" termination state) is sometime logged as a server close ("SC--" termination state) instead. It happens because sometime the connection failure to the server s1 is detected by haproxy before the client c2 aborts. There is no retries and the connection timeout is set to 100ms. So, to work, the client abort must be performed and detected by haproxy in less than 100ms. To fix the issue, the c2 client is now routed to a backend with a connection timeout set to 1 second and 10 retries. It should be large enough to detect the client aborts (~10s) In addition, there is another race condition when the script is started. sometime, server s1 is not stopped when the first client sends its request. So a barrier was added to be sure it is stopped before starting to send requests. And we wait to be sure the server is detected as DOWN to unblock the barrier. It is performed by a dedicated backend with an healthcheck on the server s1. This patch should solve issue #1664.
2022-05-17 13:08:22 +00:00
use_backend be1_1 if { path /c1 }
use_backend be1_2 if { path /c2 }
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
frontend fe2
option httplog
log ${S_addr}:${S_port} local0 debug err
bind "fd@${fe2}"
use_backend be2
REGTESTS: abortonclose: Fix some race conditions Depending on the timing, the second client that should be reported as a client abort during connection attempt ("CC--" termination state) is sometime logged as a server close ("SC--" termination state) instead. It happens because sometime the connection failure to the server s1 is detected by haproxy before the client c2 aborts. There is no retries and the connection timeout is set to 100ms. So, to work, the client abort must be performed and detected by haproxy in less than 100ms. To fix the issue, the c2 client is now routed to a backend with a connection timeout set to 1 second and 10 retries. It should be large enough to detect the client aborts (~10s) In addition, there is another race condition when the script is started. sometime, server s1 is not stopped when the first client sends its request. So a barrier was added to be sure it is stopped before starting to send requests. And we wait to be sure the server is detected as DOWN to unblock the barrier. It is performed by a dedicated backend with an healthcheck on the server s1. This patch should solve issue #1664.
2022-05-17 13:08:22 +00:00
backend be1_1
server srv1 ${s1_addr}:${s1_port}
backend be1_2
timeout connect 1s
retries 10
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
server srv1 ${s1_addr}:${s1_port}
backend be2
server srv1 ${s2_addr}:${s2_port} maxconn 1
REGTESTS: abortonclose: Fix some race conditions Depending on the timing, the second client that should be reported as a client abort during connection attempt ("CC--" termination state) is sometime logged as a server close ("SC--" termination state) instead. It happens because sometime the connection failure to the server s1 is detected by haproxy before the client c2 aborts. There is no retries and the connection timeout is set to 100ms. So, to work, the client abort must be performed and detected by haproxy in less than 100ms. To fix the issue, the c2 client is now routed to a backend with a connection timeout set to 1 second and 10 retries. It should be large enough to detect the client aborts (~10s) In addition, there is another race condition when the script is started. sometime, server s1 is not stopped when the first client sends its request. So a barrier was added to be sure it is stopped before starting to send requests. And we wait to be sure the server is detected as DOWN to unblock the barrier. It is performed by a dedicated backend with an healthcheck on the server s1. This patch should solve issue #1664.
2022-05-17 13:08:22 +00:00
backend check
server srv1 ${s1_addr}:${s1_port} check
log ${S_addr}:${S_port} local0 debug alert
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
} -start
REGTESTS: abortonclose: Fix some race conditions Depending on the timing, the second client that should be reported as a client abort during connection attempt ("CC--" termination state) is sometime logged as a server close ("SC--" termination state) instead. It happens because sometime the connection failure to the server s1 is detected by haproxy before the client c2 aborts. There is no retries and the connection timeout is set to 100ms. So, to work, the client abort must be performed and detected by haproxy in less than 100ms. To fix the issue, the c2 client is now routed to a backend with a connection timeout set to 1 second and 10 retries. It should be large enough to detect the client aborts (~10s) In addition, there is another race condition when the script is started. sometime, server s1 is not stopped when the first client sends its request. So a barrier was added to be sure it is stopped before starting to send requests. And we wait to be sure the server is detected as DOWN to unblock the barrier. It is performed by a dedicated backend with an healthcheck on the server s1. This patch should solve issue #1664.
2022-05-17 13:08:22 +00:00
# Wait s1 was detected as DOWN
barrier b0 sync
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
# No server, wait all connection retries : SC--
client c1 -connect ${h1_fe1_sock} {
txreq -url /c1
REGTESTS: abortonclose: after retries, 503 is expected, not close The abortonclose test was only expecting a close after all server retries were exhausted, it didn't check for the pending 503, which fails with new versions of vtest starting with commit 8d6c6bd ("Leak-plugging on barriers"). This may be backported, but carefully in case older versions would really close without responding.
2021-08-20 09:12:47 +00:00
rxresp
expect resp.status == 503
REGTESTS: Add script to test abortonclose option This script test abortonclose option for HTTP/1 client only. It may be backported as far as 2.0. But on the 2.2 and prior, the syslog part must be adapted to catch log messages emitted by proxy during HAProxy startup. Following lines must be added : recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe1 started." recv expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy fe2 started."
2021-04-07 12:37:07 +00:00
} -run
# Wait c1 log entry
barrier b2 sync
# No server, abort during connections retries : CC--
client c2 -connect ${h1_fe1_sock} {
txreq -url /c2
} -run
# server with maxconn=1, abort waiting the server reply : CH--
client c3 -connect ${h1_fe2_sock} {
txreq -url /c3
# Wait c4 log entry
barrier b2 sync
} -start
# server with maxconn=1, abort waiting in the queue (c3 still attached) : CQ--
client c4 -connect ${h1_fe2_sock} {
# Wait s2 receives c3 request
barrier b1 sync
txreq -url /c4
delay .2
} -run
client c3 -wait
# unlock s2
barrier b3 sync
syslog S -wait