2012-01-25 12:11:04 -05:00
|
|
|
start_server {tags {"obuf-limits"}} {
|
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} {
|
|
|
|
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]
|
|
|
|
assert_equal {} [read $fd]
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
# It is important to use one write, in TLS mode independant writes seem
|
|
|
|
# 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
|
|
|
|
set fd [$rd2 channel]
|
|
|
|
assert_equal {} [read $fd]
|
|
|
|
}
|
|
|
|
|
|
|
|
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]
|
|
|
|
}
|
2012-01-25 12:11:04 -05:00
|
|
|
}
|