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/checks/tcp-check_min-recv.vtc

69 lines
1.9 KiB
Plaintext
Raw Permalink Normal View History

MINOR: checks: add min-recv tcp-check expect option Some expect rules cannot be satisfied due to inherent ambiguity towards the received data: in the absence of match, the current behavior is to be forced to wait either the end of the connection or a buffer full, whichever comes first. Only then does the matching diagnostic is considered conclusive. For instance : tcp-check connect tcp-check expect !rstring "^error" tcp-check expect string "valid" This check will only succeed if the connection is closed by the server before the check timeout. Otherwise the first expect rule will wait for more data until "^error" regex matches or the check expires. Allow the user to explicitly define an amount of data that will be considered enough to determine the value of the check. This allows succeeding on negative rstring rules, as previously in valid condition no match happened, and the matching was repeated until the end of the connection. This could timeout the check while no error was happening. [Cf: I slighly updated the patch. The parameter was renamed and the value is a signed integer to support -1 as default value to ignore the parameter.]
2020-02-07 14:37:17 +00:00
varnishtest "tcp-check negative bounded regex match"
#EXCLUDE_TARGETS=freebsd,osx,generic
#REGTEST_TYPE=slow
#REQUIRE_VERSION=2.2
# This test use a negative expect rule and verify that setting a required
# minimum amount of data to match.
feature ignore_unknown_macro
syslog S1 -level notice {
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be1/srv1 failed, reason: Layer7 timeout.*at step 2 of tcp-check"
} -start
syslog S2 -level notice {
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be2/srv1 succeeded"
} -start
server s1 {
send "valid"
delay 0.2
expect_close
} -start
server s2 {
send "valid"
recv 10
send "valid"
delay 0.2
expect_close
} -start
haproxy h1 -conf {
defaults
mode tcp
REGTESTS: extend the default I/O timeouts and make them overridable With the CI occasionally slowing down, we're starting to see again some spurious failures despite the long 1-second timeouts. This reports false positives that are disturbing and doesn't provide as much value as this could. However at this delay it already becomes a pain for developers to wait for the tests to complete. This commit adds support for the new environment variable HAPROXY_TEST_TIMEOUT that will allow anyone to modify the connect, client and server timeouts. It was set to 5 seconds by default, which should be plenty for quite some time in the CI. All relevant values that were 200ms or above were replaced by this one. A few larger values were left as they are special. One test for the set-timeout action that used to rely on a fixed 1-sec value was extended to a fixed 5-sec, as the timeout is normally not reached, but it needs to be known to compare the old and new values.
2021-11-18 16:46:22 +00:00
timeout connect "${HAPROXY_TEST_TIMEOUT-5s}"
timeout check "${HAPROXY_TEST_TIMEOUT-5s}"
timeout server "${HAPROXY_TEST_TIMEOUT-5s}"
timeout client "${HAPROXY_TEST_TIMEOUT-5s}"
MINOR: checks: add min-recv tcp-check expect option Some expect rules cannot be satisfied due to inherent ambiguity towards the received data: in the absence of match, the current behavior is to be forced to wait either the end of the connection or a buffer full, whichever comes first. Only then does the matching diagnostic is considered conclusive. For instance : tcp-check connect tcp-check expect !rstring "^error" tcp-check expect string "valid" This check will only succeed if the connection is closed by the server before the check timeout. Otherwise the first expect rule will wait for more data until "^error" regex matches or the check expires. Allow the user to explicitly define an amount of data that will be considered enough to determine the value of the check. This allows succeeding on negative rstring rules, as previously in valid condition no match happened, and the matching was repeated until the end of the connection. This could timeout the check while no error was happening. [Cf: I slighly updated the patch. The parameter was renamed and the value is a signed integer to support -1 as default value to ignore the parameter.]
2020-02-07 14:37:17 +00:00
backend be1
REGTESTS: make tcp-check_min-recv fail fast This test was dependent on the check/server timeout to detect a failure, which is not logical since we also use that one as an upper bound for success in the second test, and that needlessly extends the test duration. Let's make sur the timeout strikes immediately with only 1 ms timeout. Now the total tests time is around 5.3-5.4s down from 8.7s in dev14. There is still quite some room for improvement in the peers tests which all wait 2s before starting but this will be more complicated.
2021-11-18 16:26:25 +00:00
# must fail fast
timeout check 1
timeout server 1
MINOR: checks: add min-recv tcp-check expect option Some expect rules cannot be satisfied due to inherent ambiguity towards the received data: in the absence of match, the current behavior is to be forced to wait either the end of the connection or a buffer full, whichever comes first. Only then does the matching diagnostic is considered conclusive. For instance : tcp-check connect tcp-check expect !rstring "^error" tcp-check expect string "valid" This check will only succeed if the connection is closed by the server before the check timeout. Otherwise the first expect rule will wait for more data until "^error" regex matches or the check expires. Allow the user to explicitly define an amount of data that will be considered enough to determine the value of the check. This allows succeeding on negative rstring rules, as previously in valid condition no match happened, and the matching was repeated until the end of the connection. This could timeout the check while no error was happening. [Cf: I slighly updated the patch. The parameter was renamed and the value is a signed integer to support -1 as default value to ignore the parameter.]
2020-02-07 14:37:17 +00:00
log ${S1_addr}:${S1_port} len 2048 local0
option tcp-check
option log-health-checks
tcp-check connect
tcp-check expect !rstring "^error" comment "negative check"
tcp-check expect string "valid" comment "positive check"
tcp-check send "0123456789"
tcp-check expect string "valid" comment "positive check"
server srv1 ${s1_addr}:${s1_port} check inter 200ms rise 1 fall 1
backend be2
log ${S2_addr}:${S2_port} len 2048 local0
option tcp-check
option log-health-checks
tcp-check connect
tcp-check expect min-recv 5 !rstring "^error" comment "negative check"
tcp-check expect string "valid" comment "positive check"
tcp-check send "0123456789"
tcp-check expect string "valid" comment "positive check"
server srv1 ${s2_addr}:${s2_port} check inter 200ms rise 1 fall 1
} -start
syslog S1 -wait
syslog S2 -wait