- 07 Apr, 2020 6 commits
-
-
Guy Benoish authored
There is an inherent race between the deferring client and the "main" client of the test: While the deferring client issues a blocking command, we can't know for sure that by the time the "main" client tries to issue another command (Usually one that unblocks the deferring client) the deferring client is even blocked... For lack of a better choice this commit uses TCL's 'after' in order to give some time for the deferring client to issues its blocking command before the "main" client does its thing. This problem probably exists in many other tests but this commit tries to fix blockonkeys.tcl
-
Valentino Geron authored
-
Guy Benoish authored
-
Guy Benoish authored
-
Valentino Geron authored
First, we must parse the IDs, so that we abort ASAP. The return value of this command cannot be an error if the client successfully acknowledged some messages, so it should be executed in a "all or nothing" fashion.
-
Guy Benoish authored
By using a "circular BRPOPLPUSH"-like scenario it was possible the get the same client on db->blocking_keys twice (See comment in moduleTryServeClientBlockedOnKey) The fix was actually already implememnted in moduleTryServeClientBlockedOnKey but it had a bug: the funxction should return 0 or 1 (not OK or ERR) Other changes: 1. Added two commands to blockonkeys.c test module (To reproduce the case described above) 2. Simplify blockonkeys.c in order to make testing easier 3. cast raxSize() to avoid warning with format spec
-
- 31 Mar, 2020 4 commits
-
-
Guy Benoish authored
Makse sure call() doesn't wrap replicated commands with a redundant MULTI/EXEC Other, unrelated changes: 1. Formatting compiler warning in INFO CLIENTS 2. Use CLIENT_ID_AOF instead of UINT64_MAX
-
Guy Benoish authored
Other changes: Support stream in serverLogObjectDebugInfo
-
antirez authored
-
Oran Agra authored
the AOF will be loaded successfully, but the stream will be missing, i.e inconsistencies with the original db. this was because XADD with id of 0-0 would error. add a test to reproduce.
-
- 25 Mar, 2020 4 commits
-
-
Oran Agra authored
Redis refusing to run MULTI or EXEC during script timeout may cause partial transactions to run. 1) if the client sends MULTI+commands+EXEC in pipeline without waiting for response, but these arrive to the shards partially while there's a busy script, and partially after it eventually finishes: we'll end up running only part of the transaction (since multi was ignored, and exec would fail). 2) similar to the above if EXEC arrives during busy script, it'll be ignored and the client state remains in a transaction. the 3rd test which i added for a case where MULTI and EXEC are ok, and only the body arrives during busy script was already handled correctly since processCommand calls flagTransaction
-
antirez authored
-
bodong.ybd authored
-
antirez authored
-
- 27 Feb, 2020 7 commits
-
-
Oran Agra authored
in some cases we were trying to kill the fork before it got created
-
Oran Agra authored
it seems that running two clients at a time is ok too, resuces action time from 20 minutes to 10. we'll use this for now, and if one day it won't be enough we'll have to run just the sensitive tests one by one separately from the others. this commit also fixes an issue with the defrag test that appears to be very rare.
-
Oran Agra authored
seems that github actions are slow, using just one client to reduce false positives. also adding verbose, testing only on latest ubuntu, and building on older one. when doing that, i can reduce the test threshold back to something saner
-
Oran Agra authored
I saw that the new defag test for list was failing in CI recently, so i reduce it's threshold from 12 to 60. besides that, i add / improve the latency test for that other two defrag tests (add a sensitive latency and digest / save checks) and fix bad usage of debug populate (can't overrides existing keys). this was the original intention, which creates higher fragmentation.
-
Oran Agra authored
When active defrag kicks in and finds a big list, it will create a bookmark to a node so that it is able to resume iteration from that node later. The quicklist manages that bookmark, and updates it in case that node is deleted. This will increase memory usage only on lists of over 1000 (see active-defrag-max-scan-fields) quicklist nodes (1000 ziplists, not 1000 items) by 16 bytes. In 32 bit build, this change reduces the maximum effective config of list-compress-depth and list-max-ziplist-size (from 32767 to 8191)
-
Guy Benoish authored
-
antirez authored
-
- 12 Feb, 2020 3 commits
- 04 Feb, 2020 3 commits
-
-
WuYunlong authored
-
Guy Benoish authored
This bug affected RM_StringToLongDouble and HINCRBYFLOAT. I added tests for both cases. Main changes: 1. Fixed string2ld to fail if string contains \0 in the middle 2. Use string2ld in getLongDoubleFromObject - No point of having duplicated code here The two changes above broke RM_SaveLongDouble/RM_LoadLongDouble because the long double string was saved with length+1 (An innocent mistake, but it's actually a bug - The length passed to RM_SaveLongDouble should not include the last \0).
-
Guy Benoish authored
If a blocked module client times-out (or disconnects, unblocked by CLIENT command, etc.) we need to call moduleUnblockClient in order to free memory allocated by the module sub-system and blocked-client private data Other changes: Made blockedonkeys.tcl tests a bit more aggressive in order to smoke-out potential memory leaks
-
- 10 Jan, 2020 1 commit
-
-
Guy Benoish authored
This commit solves the following bug: 127.0.0.1:6379> XGROUP CREATE x grp $ MKSTREAM OK 127.0.0.1:6379> XADD x 666 f v "666-0" 127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x > 1) 1) "x" 2) 1) 1) "666-0" 2) 1) "f" 2) "v" 127.0.0.1:6379> XADD x 667 f v "667-0" 127.0.0.1:6379> XDEL x 667 (integer) 1 127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x > 1) 1) "x" 2) (empty array) The root cause is that we use s->last_id in streamCompareID while we should use the last *valid* ID
-
- 29 Dec, 2019 2 commits
-
-
Guy Benoish authored
This commit solves several edge cases that are related to exhausting the streamID limits: We should correctly calculate the succeeding streamID instead of blindly incrementing 'seq' This affects both XREAD and XADD. Other (unrelated) changes: Reply with a better error message when trying to add an entry to a stream that has exhausted last_id
-
Oran Agra authored
- make lua-replicate-commands mutable (it never was, but i don't see why) - make tcp-backlog immutable (fix a recent refactory mistake) - increase the max limit of a few configs to match what they were before the recent refactory
-
- 18 Dec, 2019 2 commits
-
-
zhaozhao.zz authored
- 17 Dec, 2019 1 commit
-
-
Madelyn Olson authored
-
- 12 Dec, 2019 1 commit
-
-
Yossi Gottlieb authored
With the previous API, a NULL return value was ambiguous and could represent either an old value of NULL or an error condition. The new API returns a status code and allows the old value to be returned by-reference. This commit also includes test coverage based on tests/modules/datatype.c which did not exist at the time of the original commit.
-
- 28 Nov, 2019 1 commit
-
-
Oran Agra authored
Changes in behavior: - Change server.stream_node_max_entries from int64_t to long long, so that it can be used by the generic infra - standard error reply instead of "repl-backlog-size must be 1 or greater" and such - tls-port and a few TLS booleans were readable (config get) even when USE_OPENSSL was off (now they aren't) - syslog-enabled, syslog-ident, cluster-enabled, appendfilename, and supervised didn't have a get (now they do) - pidfile was initialized to NULL in InitServerConfig but had CONFIG_DEFAULT_PID_FILE in rewriteConfig (so the real default was "", but rewrite would cause it to be set), fixed the rewrite. - TLS config in server.h was uninitialized (if no tls config args were provided) Adding test for sanity and coverage
-
- 20 Nov, 2019 1 commit
-
-
Daniel Dai authored
-
- 19 Nov, 2019 2 commits
-
-
Oran Agra authored
there were two lssues, one is taht BGREWRITEAOF failed since the initial one was still in progress the solution for this one is to enable appendonly from the server startup so there's no initial aofrw. the other problem was 0 loading progress events, theory is that on some platforms a sleep of 1 will cause a much greater delay due to the context switch, but on other platform it doesn't. in theory a sleep of 100 micro for 1k keys whould take 100ms, and with hz of 500 we should be gettering 50 events (one every 2ms). in practise it doesn't work like that, so trying to find a sleep that would be long enough but still not cause the test to take too long.
-
antirez authored
-
- 13 Nov, 2019 1 commit
-
-
Guy Benoish authored
Calling XADD with 0-0 or 0 would result in creating an empty key and storing it in the database. Even worse, because XADD will reply with error the action will not be replicated, creating a master-replica inconsistency
-
- 11 Nov, 2019 1 commit
-
-
Oran Agra authored
- Adding RM_ScanKey - Adding tests for RM_ScanKey - Refactoring RM_Scan API Changes in RM_Scan - cleanup in docs and coding convention - Moving out of experimantal Api - Adding ctx to scan callback - Dont use cursor of -1 as an indication of done (can be a valid cursor) - Set errno when returning 0 for various reasons - Rename Cursor to ScanCursor - Test filters key that are not strings, and opens a key if NULL
-