2021-06-09 08:13:24 -04:00
|
|
|
start_server {tags {"obuf-limits external:skip"}} {
|
2021-08-29 08:03:05 -04:00
|
|
|
test {CONFIG SET client-output-buffer-limit} {
|
|
|
|
set oldval [lindex [r config get client-output-buffer-limit] 1]
|
|
|
|
|
|
|
|
catch {r config set client-output-buffer-limit "wrong number"} e
|
|
|
|
assert_match {*Wrong*arguments*} $e
|
|
|
|
|
|
|
|
catch {r config set client-output-buffer-limit "invalid_class 10mb 10mb 60"} e
|
|
|
|
assert_match {*Invalid*client*class*} $e
|
|
|
|
catch {r config set client-output-buffer-limit "master 10mb 10mb 60"} e
|
|
|
|
assert_match {*Invalid*client*class*} $e
|
|
|
|
|
|
|
|
catch {r config set client-output-buffer-limit "normal 10mbs 10mb 60"} e
|
|
|
|
assert_match {*Error*hard*} $e
|
|
|
|
|
|
|
|
catch {r config set client-output-buffer-limit "replica 10mb 10mbs 60"} e
|
|
|
|
assert_match {*Error*soft*} $e
|
|
|
|
|
|
|
|
catch {r config set client-output-buffer-limit "pubsub 10mb 10mb 60s"} e
|
|
|
|
assert_match {*Error*soft_seconds*} $e
|
|
|
|
|
|
|
|
r config set client-output-buffer-limit "normal 1mb 2mb 60 replica 3mb 4mb 70 pubsub 5mb 6mb 80"
|
|
|
|
set res [lindex [r config get client-output-buffer-limit] 1]
|
|
|
|
assert_equal $res "normal 1048576 2097152 60 slave 3145728 4194304 70 pubsub 5242880 6291456 80"
|
|
|
|
|
|
|
|
# Set back to the original value.
|
|
|
|
r config set client-output-buffer-limit $oldval
|
|
|
|
}
|
|
|
|
|
2012-01-25 12:34:56 -05:00
|
|
|
test {Client output buffer hard limit is enforced} {
|
2012-01-25 12:11:04 -05:00
|
|
|
r config set client-output-buffer-limit {pubsub 100000 0 0}
|
|
|
|
set rd1 [redis_deferring_client]
|
|
|
|
|
|
|
|
$rd1 subscribe foo
|
|
|
|
set reply [$rd1 read]
|
|
|
|
assert {$reply eq "subscribe foo 1"}
|
|
|
|
|
|
|
|
set omem 0
|
|
|
|
while 1 {
|
|
|
|
r publish foo bar
|
|
|
|
set clients [split [r client list] "\r\n"]
|
|
|
|
set c [split [lindex $clients 1] " "]
|
|
|
|
if {![regexp {omem=([0-9]+)} $c - omem]} break
|
|
|
|
if {$omem > 200000} break
|
|
|
|
}
|
2019-05-13 11:27:06 -04:00
|
|
|
assert {$omem >= 70000 && $omem < 200000}
|
2012-01-25 12:11:04 -05:00
|
|
|
$rd1 close
|
|
|
|
}
|
2021-05-04 06:45:08 -04:00
|
|
|
|
|
|
|
foreach {soft_limit_time wait_for_timeout} {3 yes
|
|
|
|
4 no } {
|
|
|
|
if $wait_for_timeout {
|
|
|
|
set test_name "Client output buffer soft limit is enforced if time is overreached"
|
|
|
|
} else {
|
|
|
|
set test_name "Client output buffer soft limit is not enforced too early and is enforced when no traffic"
|
2012-01-25 12:34:56 -05:00
|
|
|
}
|
|
|
|
|
2021-05-04 06:45:08 -04:00
|
|
|
test $test_name {
|
|
|
|
r config set client-output-buffer-limit "pubsub 0 100000 $soft_limit_time"
|
|
|
|
set soft_limit_time [expr $soft_limit_time*1000]
|
|
|
|
set rd1 [redis_deferring_client]
|
2012-01-25 12:34:56 -05:00
|
|
|
|
2021-05-04 06:45:08 -04:00
|
|
|
$rd1 client setname test_client
|
|
|
|
set reply [$rd1 read]
|
|
|
|
assert {$reply eq "OK"}
|
2012-01-25 12:34:56 -05:00
|
|
|
|
2021-05-04 06:45:08 -04:00
|
|
|
$rd1 subscribe foo
|
|
|
|
set reply [$rd1 read]
|
|
|
|
assert {$reply eq "subscribe foo 1"}
|
|
|
|
|
|
|
|
set omem 0
|
|
|
|
set start_time 0
|
|
|
|
set time_elapsed 0
|
|
|
|
set last_under_limit_time [clock milliseconds]
|
|
|
|
while 1 {
|
|
|
|
r publish foo [string repeat "x" 1000]
|
|
|
|
set clients [split [r client list] "\r\n"]
|
|
|
|
set c [lsearch -inline $clients *name=test_client*]
|
|
|
|
if {$start_time != 0} {
|
|
|
|
set time_elapsed [expr {[clock milliseconds]-$start_time}]
|
|
|
|
# Make sure test isn't taking too long
|
|
|
|
assert {$time_elapsed <= [expr $soft_limit_time+3000]}
|
|
|
|
}
|
|
|
|
if {$wait_for_timeout && $c == ""} {
|
|
|
|
# Make sure we're disconnected when we reach the soft limit
|
|
|
|
assert {$omem >= 100000 && $time_elapsed >= $soft_limit_time}
|
|
|
|
break
|
|
|
|
} else {
|
|
|
|
assert {[regexp {omem=([0-9]+)} $c - omem]}
|
|
|
|
}
|
|
|
|
if {$omem > 100000} {
|
|
|
|
if {$start_time == 0} {set start_time $last_under_limit_time}
|
|
|
|
if {!$wait_for_timeout && $time_elapsed >= [expr $soft_limit_time-1000]} break
|
|
|
|
# Slow down loop when omem has reached the limit.
|
|
|
|
after 10
|
|
|
|
} else {
|
|
|
|
# if the OS socket buffers swallowed what we previously filled, reset the start timer.
|
|
|
|
set start_time 0
|
|
|
|
set last_under_limit_time [clock milliseconds]
|
|
|
|
}
|
2021-04-19 03:08:07 -04:00
|
|
|
}
|
2021-05-04 06:45:08 -04:00
|
|
|
|
|
|
|
if {!$wait_for_timeout} {
|
|
|
|
# After we completely stopped the traffic, wait for soft limit to time out
|
|
|
|
set timeout [expr {$soft_limit_time+1500 - ([clock milliseconds]-$start_time)}]
|
|
|
|
wait_for_condition [expr $timeout/10] 10 {
|
|
|
|
[lsearch [split [r client list] "\r\n"] *name=test_client*] == -1
|
|
|
|
} else {
|
|
|
|
fail "Soft limit timed out but client still connected"
|
|
|
|
}
|
2012-01-25 12:34:56 -05:00
|
|
|
}
|
2021-05-04 06:45:08 -04:00
|
|
|
|
|
|
|
$rd1 close
|
2012-01-25 12:34:56 -05:00
|
|
|
}
|
|
|
|
}
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
|
|
|
|
test {No response for single command if client output buffer hard limit is enforced} {
|
Added INFO LATENCYSTATS section: latency by percentile distribution/latency by cumulative distribution of latencies (#9462)
# Short description
The Redis extended latency stats track per command latencies and enables:
- exporting the per-command percentile distribution via the `INFO LATENCYSTATS` command.
**( percentile distribution is not mergeable between cluster nodes ).**
- exporting the per-command cumulative latency distributions via the `LATENCY HISTOGRAM` command.
Using the cumulative distribution of latencies we can merge several stats from different cluster nodes
to calculate aggregate metrics .
By default, the extended latency monitoring is enabled since the overhead of keeping track of the
command latency is very small.
If you don't want to track extended latency metrics, you can easily disable it at runtime using the command:
- `CONFIG SET latency-tracking no`
By default, the exported latency percentiles are the p50, p99, and p999.
You can alter them at runtime using the command:
- `CONFIG SET latency-tracking-info-percentiles "0.0 50.0 100.0"`
## Some details:
- The total size per histogram should sit around 40 KiB. We only allocate those 40KiB when a command
was called for the first time.
- With regards to the WRITE overhead As seen below, there is no measurable overhead on the achievable
ops/sec or full latency spectrum on the client. Including also the measured redis-benchmark for unstable
vs this branch.
- We track from 1 nanosecond to 1 second ( everything above 1 second is considered +Inf )
## `INFO LATENCYSTATS` exposition format
- Format: `latency_percentiles_usec_<CMDNAME>:p0=XX,p50....`
## `LATENCY HISTOGRAM [command ...]` exposition format
Return a cumulative distribution of latencies in the format of a histogram for the specified command names.
The histogram is composed of a map of time buckets:
- Each representing a latency range, between 1 nanosecond and roughly 1 second.
- Each bucket covers twice the previous bucket's range.
- Empty buckets are not printed.
- Everything above 1 sec is considered +Inf.
- At max there will be log2(1000000000)=30 buckets
We reply a map for each command in the format:
`<command name> : { `calls`: <total command calls> , `histogram` : { <bucket 1> : latency , < bucket 2> : latency, ... } }`
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-05 07:01:05 -05:00
|
|
|
r config set latency-tracking no
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
r config set client-output-buffer-limit {normal 100000 0 0}
|
|
|
|
# Total size of all items must be more than 100k
|
|
|
|
set item [string repeat "x" 1000]
|
|
|
|
for {set i 0} {$i < 150} {incr i} {
|
|
|
|
r lpush mylist $item
|
|
|
|
}
|
|
|
|
set orig_mem [s used_memory]
|
|
|
|
# Set client name and get all items
|
|
|
|
set rd [redis_deferring_client]
|
|
|
|
$rd client setname mybiglist
|
|
|
|
assert {[$rd read] eq "OK"}
|
|
|
|
$rd lrange mylist 0 -1
|
|
|
|
$rd flush
|
|
|
|
after 100
|
|
|
|
|
|
|
|
# Before we read reply, redis will close this client.
|
|
|
|
set clients [r client list]
|
|
|
|
assert_no_match "*name=mybiglist*" $clients
|
|
|
|
set cur_mem [s used_memory]
|
|
|
|
# 10k just is a deviation threshold
|
|
|
|
assert {$cur_mem < 10000 + $orig_mem}
|
|
|
|
|
|
|
|
# Read nothing
|
|
|
|
set fd [$rd channel]
|
2022-07-03 06:34:14 -04:00
|
|
|
assert_equal {} [$rd rawread]
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
}
|
|
|
|
|
2020-09-27 10:13:33 -04:00
|
|
|
# Note: This test assumes that what's written with one write, will be read by redis in one read.
|
|
|
|
# this assumption is wrong, but seem to work empirically (for now)
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
test {No response for multi commands in pipeline if client output buffer limit is enforced} {
|
|
|
|
r config set client-output-buffer-limit {normal 100000 0 0}
|
|
|
|
set value [string repeat "x" 10000]
|
|
|
|
r set bigkey $value
|
|
|
|
set rd1 [redis_deferring_client]
|
|
|
|
set rd2 [redis_deferring_client]
|
|
|
|
$rd2 client setname multicommands
|
|
|
|
assert_equal "OK" [$rd2 read]
|
2020-09-27 10:13:33 -04:00
|
|
|
|
|
|
|
# Let redis sleep 1s firstly
|
|
|
|
$rd1 debug sleep 1
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
$rd1 flush
|
|
|
|
after 100
|
|
|
|
|
2020-09-27 10:13:33 -04:00
|
|
|
# Create a pipeline of commands that will be processed in one socket read.
|
2021-06-10 08:39:33 -04:00
|
|
|
# It is important to use one write, in TLS mode independent writes seem
|
2020-09-27 10:13:33 -04:00
|
|
|
# to wait for response from the server.
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
# Total size should be less than OS socket buffer, redis can
|
|
|
|
# execute all commands in this pipeline when it wakes up.
|
2020-09-27 10:13:33 -04:00
|
|
|
set buf ""
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
for {set i 0} {$i < 15} {incr i} {
|
2020-09-27 10:13:33 -04:00
|
|
|
append buf "set $i $i\r\n"
|
|
|
|
append buf "get $i\r\n"
|
|
|
|
append buf "del $i\r\n"
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
# One bigkey is 10k, total response size must be more than 100k
|
2020-09-27 10:13:33 -04:00
|
|
|
append buf "get bigkey\r\n"
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
}
|
2020-09-27 10:13:33 -04:00
|
|
|
$rd2 write $buf
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
$rd2 flush
|
|
|
|
after 100
|
|
|
|
|
|
|
|
# Reds must wake up if it can send reply
|
|
|
|
assert_equal "PONG" [r ping]
|
|
|
|
set clients [r client list]
|
|
|
|
assert_no_match "*name=multicommands*" $clients
|
2022-07-03 06:34:14 -04:00
|
|
|
assert_equal {} [$rd2 rawread]
|
Don't write replies if close the client ASAP (#7202)
Before this commit, we would have continued to add replies to the reply buffer even if client
output buffer limit is reached, so the used memory would keep increasing over the configured limit.
What's more, we shouldn’t write any reply to the client if it is set 'CLIENT_CLOSE_ASAP' flag
because that doesn't conform to its definition and we will close all clients flagged with
'CLIENT_CLOSE_ASAP' in ‘beforeSleep’.
Because of code execution order, before this, we may firstly write to part of the replies to
the socket before disconnecting it, but in fact, we may can’t send the full replies to clients
since OS socket buffer is limited. But this unexpected behavior makes some commands work well,
for instance ACL DELUSER, if the client deletes the current user, we need to send reply to client
and close the connection, but before, we close the client firstly and write the reply to reply
buffer. secondly, we shouldn't do this despite the fact it works well in most cases.
We add a flag 'CLIENT_CLOSE_AFTER_COMMAND' to mark clients, this flag means we will close the
client after executing commands and send all entire replies, so that we can write replies to
reply buffer during executing commands, send replies to clients, and close them later.
We also fix some implicit problems. If client output buffer limit is enforced in 'multi/exec',
all commands will be executed completely in redis and clients will not read any reply instead of
partial replies. Even more, if the client executes 'ACL deluser' the using user in 'multi/exec',
it will not read the replies after 'ACL deluser' just like before executing 'client kill' itself
in 'multi/exec'.
We added some tests for output buffer limit breach during multi-exec and using a pipeline of
many small commands rather than one with big response.
Co-authored-by: Oran Agra <oran@redislabs.com>
2020-09-24 09:01:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
test {Execute transactions completely even if client output buffer limit is enforced} {
|
|
|
|
r config set client-output-buffer-limit {normal 100000 0 0}
|
|
|
|
# Total size of all items must be more than 100k
|
|
|
|
set item [string repeat "x" 1000]
|
|
|
|
for {set i 0} {$i < 150} {incr i} {
|
|
|
|
r lpush mylist2 $item
|
|
|
|
}
|
|
|
|
|
|
|
|
# Output buffer limit is enforced during executing transaction
|
|
|
|
r client setname transactionclient
|
|
|
|
r set k1 v1
|
|
|
|
r multi
|
|
|
|
r set k2 v2
|
|
|
|
r get k2
|
|
|
|
r lrange mylist2 0 -1
|
|
|
|
r set k3 v3
|
|
|
|
r del k1
|
|
|
|
catch {[r exec]} e
|
|
|
|
assert_match "*I/O error*" $e
|
|
|
|
reconnect
|
|
|
|
set clients [r client list]
|
|
|
|
assert_no_match "*name=transactionclient*" $clients
|
|
|
|
|
|
|
|
# Transactions should be executed completely
|
|
|
|
assert_equal {} [r get k1]
|
|
|
|
assert_equal "v2" [r get k2]
|
|
|
|
assert_equal "v3" [r get k3]
|
|
|
|
}
|
Obuf limit, exit during loop in *RAND* commands and KEYS (#11676)
Related to the hang reported in #11671
Currently, redis can disconnect a client due to reaching output buffer limit,
it'll also avoid feeding that output buffer with more data, but it will keep
running the loop in the command (despite the client already being marked for
disconnection)
This PR is an attempt to mitigate the problem, specifically for commands that
are easy to abuse, specifically: KEYS, HRANDFIELD, SRANDMEMBER, ZRANDMEMBER.
The RAND family of commands can take a negative COUNT argument (which is not
bound to the number of elements in the key), so it's enough to create a key
with one field, and then these commands can be used to hang redis.
For KEYS the caller can use the existing keyspace in redis (if big enough).
2023-01-16 06:51:18 -05:00
|
|
|
|
|
|
|
test "Obuf limit, HRANDFIELD with huge count stopped mid-run" {
|
|
|
|
r config set client-output-buffer-limit {normal 1000000 0 0}
|
|
|
|
r hset myhash a b
|
|
|
|
catch {r hrandfield myhash -999999999} e
|
|
|
|
assert_match "*I/O error*" $e
|
|
|
|
reconnect
|
|
|
|
}
|
|
|
|
|
|
|
|
test "Obuf limit, KEYS stopped mid-run" {
|
|
|
|
r config set client-output-buffer-limit {normal 100000 0 0}
|
|
|
|
populate 1000 "long-key-name-prefix-of-100-chars-------------------------------------------------------------------"
|
|
|
|
catch {r keys *} e
|
|
|
|
assert_match "*I/O error*" $e
|
|
|
|
reconnect
|
|
|
|
}
|
2012-01-25 12:11:04 -05:00
|
|
|
}
|