- 10 Sep, 2020 3 commits
-
- 01 Sep, 2020 4 commits
-
-
Yossi Gottlieb authored
(cherry picked from commit f80f3f49)
-
Oran Agra authored
- the test now waits for specific set of log messages rather than wait for timeout looking for just one message. - we don't wanna sample the current length of the log after an action, due to a race, we need to start the search from the line number of the last message we where waiting for. - when attempting to trigger a full sync, use multi-exec to avoid a race where the replica manages to re-connect before we completed the set of actions that should force a full sync. - fix verify_log_message which was broken and unused (cherry picked from commit 109b5ccd)
-
Oran Agra authored
in cases where you have test name { start_server { start_server { assert } } } the exception will be thrown to the test proc, and the servers are supposed to be killed on the way out. but it seems there was always a bug of not cleaning the server stack, and recently (#7404) we started relying on that stack in order to kill them, so with that bug sometimes we would have tried to kill the same server twice, and leave one alive. luckly, in most cases the pattern is: start_server { test name { } } (cherry picked from commit 36b94943)
-
Remi Collet authored
(cherry picked from commit 3f2fbc4c)
-
- 20 Jul, 2020 3 commits
-
-
Oran Agra authored
in the majority of the cases (on this rarely used feature) we want to stop and be able to connect to the shard with redis-cli. since these are two different processes interracting with the tty we need to stop both, and we'll have to hit enter twice, but it's not that bad considering it is rarely used. (cherry picked from commit 02ef355f)
-
Oran Agra authored
* tests/valgrind: don't use debug restart DEBUG REATART causes two issues: 1. it uses execve which replaces the original process and valgrind doesn't have a chance to check for errors, so leaks go unreported. 2. valgrind report invalid calls to close() which we're unable to resolve. So now the tests use restart_server mechanism in the tests, that terminates the old server and starts a new one, new PID, but same stdout, stderr. since the stderr can contain two or more valgrind report, it is not enough to just check for the absence of leaks, we also need to check for some known errors, we do both, and fail if we either find an error, or can't find a report saying there are no leaks. other changes: - when killing a server that was already terminated we check for leaks too. - adding DEBUG LEAK which was used to test it. - adding --trace-children to valgrind, although no longer needed. - since the stdout contains two or more runs, we need slightly different way of checking if the new process is up (explicitly looking for the new PID) - move the code that handles --wait-server to happen earlier (before watching the startup message in the log), and serve the restarted server too. * squashme - CR fixes (cherry picked from commit 69ade873)
-
- 28 May, 2020 2 commits
-
-
Oran Agra authored
i.e. don't start the search from scratch hitting the used ones again. this will also reduce the likelihood of collisions (if there are any left) by increasing the time until we re-use a port we did use in the past.
-
Oran Agra authored
apparently when running tests in parallel (the default of --clients 16), there's a chance for two tests to use the same port. specifically, one test might shutdown a master and still have the replica up, and then another test will re-use the port number of master for another master, and then that replica will connect to the master of the other test. this can cause a master to count too many full syncs and fail a test if we run the tests with --single integration/psync2 --loop --stop see Probmem 2 in #7314
-
- 22 May, 2020 1 commit
-
-
WuYunlong authored
-
- 07 Apr, 2020 1 commit
-
-
Oran Agra authored
-
- 25 Mar, 2020 1 commit
-
-
bodong.ybd authored
-
- 27 Feb, 2020 3 commits
- 29 Oct, 2019 1 commit
-
-
Oran Agra authored
sometimes we have several assertions with the same condition in the same test at different stages, and when these fail (the ones that print the condition text) you don't know which one it was. other assertions didn't print the condition text (variable names), just the expected and unexpected values. So now, all assertions print context line, and conditin text. besides, one of the major differences between 'assert' and 'assert_equal', is that the later is able to print the value that doesn't match the expected. if there is a rare non-reproducible failure, it is helpful to know what was the value the test encountered and how far it was from the threshold. So now, adding assert_lessthan and assert_range that can be used in some places. were we used just 'assert { a > b }' so far.
-
- 07 Oct, 2019 2 commits
-
-
Yossi Gottlieb authored
Add configuration options for TLS protocol versions, ciphers/cipher suites selection, etc.
-
Yossi Gottlieb authored
* Introduce a connection abstraction layer for all socket operations and integrate it across the code base. * Provide an optional TLS connections implementation based on OpenSSL. * Pull a newer version of hiredis with TLS support. * Tests, redis-cli updates for TLS support.
-
- 30 Sep, 2019 1 commit
-
-
Madelyn Olson authored
-
- 17 Jul, 2019 1 commit
-
-
Oran Agra authored
now that replica can read rdb directly from the socket, it should avoid exiting on short read and instead try to re-sync. this commit tries to have minimal effects on non-diskless rdb reading. and includes a test that tries to trigger this scenario on various read cases.
-
- 08 Jul, 2019 1 commit
-
-
Oran Agra authored
The implementation of the diskless replication was currently diskless only on the master side. The slave side was still storing the received rdb file to the disk before loading it back in and parsing it. This commit adds two modes to load rdb directly from socket: 1) when-empty 2) using "swapdb" the third mode of using diskless slave by flushdb is risky and currently not included. other changes: -------------- distinguish between aof configuration and state so that we can re-enable aof only when sync eventually succeeds (and not when exiting from readSyncBulkPayload after a failed attempt) also a CONFIG GET and INFO during rdb loading would have lied When loading rdb from the network, don't kill the server on short read (that can be a network error) Fix rdb check when performed on preamble AOF tests: run replication tests for diskless slave too make replication test a bit more aggressive Add test for diskless load swapdb
-
- 12 Nov, 2018 1 commit
-
-
Oran Agra authored
-
- 04 Sep, 2018 1 commit
-
-
maya-rv authored
-
- 30 Jul, 2018 1 commit
-
-
Oran Agra authored
* allowing --single to be repeated * adding --only so that only a specific test inside a unit can be run * adding --skiptill useful to resume a test that crashed passed the problematic unit. useful together with --clients 1 * adding --skipfile to use a file containing list of tests names to skip * printing the names of the tests that are skiped by skipfile or denytags * adding --config to add config file options from command line
-
- 13 Jul, 2018 2 commits
- 26 Jun, 2018 1 commit
-
-
Oran Agra authored
* fail the test (exit code) in case of timeout. * add --wait-server to allow attaching a debugger * add --dont-clean to keep log files when tests are done
-
- 19 Dec, 2016 1 commit
-
-
antirez authored
-
- 25 Apr, 2016 1 commit
-
-
Oran Agra authored
-
- 02 Feb, 2016 1 commit
-
-
antirez authored
-
- 01 Oct, 2015 1 commit
-
-
antirez authored
-
- 05 Aug, 2015 1 commit
-
-
antirez authored
-
- 31 Mar, 2015 1 commit
-
-
antirez authored
This should likely fix a false positive when running with the --valgrind option.
-
- 21 Jan, 2015 1 commit
-
-
Matt Stancliff authored
-
- 09 Jan, 2015 1 commit
-
-
antirez authored
-
- 02 Jan, 2015 1 commit
-
-
Matt Stancliff authored
This replaces individual ziplist vs. linkedlist representations for Redis list operations. Big thanks for all the reviews and feedback from everybody in https://github.com/antirez/redis/pull/2143
-
- 28 Nov, 2014 1 commit
-
-
antirez authored
start_server now uses return value from Tcl exec to get the server pid, however this introduces errors that depend from timing: a lot of the testing code base assumed the server to be actually up and running when server_start returns. So the old code that waits to see the pid in the log file was restored.
-