- 16 Jun, 2017 1 commit
-
-
xuzhou authored
-
- 15 Jun, 2017 1 commit
-
-
antirez authored
-
- 28 Apr, 2017 2 commits
-
-
antirez authored
-
antirez authored
Experimentally verified that it can trigger the issue reverting the fix. At least on my system... Being the bug time/backlog dependant, it is very hard to tell if this test will be able to trigger the problem consistently, however even if it triggers the problem once in a while, we'll see it in the CI environment at http://ci.redis.io.
-
- 22 Apr, 2017 3 commits
-
-
antirez authored
Related to #3786.
-
antirez authored
Apparently 1.4 is too low compared to what you get in certain setups (including mine). I raised it to 1.55 that hopefully is still enough to test that the fragmentation went down from 1.7 but without incurring in issues, however the test setup may be still fragile so certain times this may lead to false positives again, it's hard to test for these things in a determinsitic way. Related to #3786.
-
oranagra authored
-
- 14 Apr, 2017 1 commit
-
-
antirez authored
And many other related Github issues... all reporting the same problem. There was probably just not enough backlog in certain unlucky runs. I'll ask people that can reporduce if they see now this as fixed as well.
-
- 15 Mar, 2017 1 commit
-
-
Oran Agra authored
-
- 22 Feb, 2017 3 commits
-
-
antirez authored
Testing with Solaris C compiler (SunOS 5.11 11.2 sun4v sparc sun4v) there were issues compiling due to atomicvar.h and running the tests also failed because of "tail" usage not conform with Solaris tail implementation. This commit fixes both the issues.
-
antirez authored
Slow systems like the original Raspberry PI need more time than 5 seconds to start the script and detect writes. After fixing the Raspberry PI can pass the unit without issues.
-
antirez authored
-
- 20 Dec, 2016 1 commit
-
-
antirez authored
We need to report all the points added into the set, not just the ones matching the Tcl distance algo.
-
- 19 Dec, 2016 1 commit
-
-
antirez authored
-
- 13 Dec, 2016 1 commit
-
-
antirez authored
-
- 05 Dec, 2016 1 commit
-
-
antirez authored
The test now uses more diverse radius sizes, especially sizes near or greater the whole earth surface are used, that are known to trigger edge cases. Moreover the PRNG seeding was probably resulting into the same sequence tested over and over again, now seeding unsing the current unix time in milliseconds. Related to #3631.
-
- 29 Nov, 2016 4 commits
- 28 Nov, 2016 2 commits
-
-
antirez authored
This actually includes two changes: 1) No newlines to take the master-slave link up when the upstream master is down. Doing this is dangerous because the sub-slave often is received replication protocol for an half-command, so can't receive newlines without desyncing the replication link, even with the code in order to cancel out the bytes that PSYNC2 was using. Moreover this is probably also not needed/sane, because anyway the slave can keep serving requests, and because if it's configured to don't serve stale data, it's a good idea, actually, to break the link. 2) When a +CONTINUE with a different ID is received, we now break connection with the sub-slaves: they need to be notified as well. This was part of the original specification but for some reason it was not implemented in the code, and was alter found as a PSYNC2 bug in the integration testing.
-
antirez authored
This is the PSYNC2 test that helped find issues in the code, and that still can show a protocol desync from time to time. Work is in progress in order to find the issue. For now the test is not enabled in "make test" and must be run manually.
-
- 18 Nov, 2016 1 commit
-
-
antirez authored
-
- 31 Oct, 2016 1 commit
-
-
antirez authored
-
- 14 Oct, 2016 1 commit
-
-
antirez authored
-
- 24 Aug, 2016 1 commit
-
-
antirez authored
-
- 27 Jul, 2016 1 commit
-
-
antirez authored
By grepping the continuous integration errors log a number of GEORADIUS tests failures were detected. Fortunately when a GEORADIUS failure happens, the test suite logs enough information in order to reproduce the problem: the PRNG seed, coordinates and radius of the query. By reproducing the issues, three different bugs were discovered and fixed in this commit. This commit also improves the already good reporting of the fuzzer and adds the failure vectors as regression tests. The issues found: 1. We need larger squares around the poles in order to cover the area requested by the user. There were already checks in order to use a smaller step (larger squares) but the limit set (+/- 67 degrees) is not enough in certain edge cases, so 66 is used now. 2. Even near the equator, when the search area center is very near the edge of the square, the north, south, west or ovest square may not be able to fully cover the specified radius. Now a test is performed at the edge of the initial guessed search area, and larger squares are used in case the test fails. 3. Because of rounding errors between Redis and Tcl, sometimes the test signaled false positives. This is now addressed. Whenever possible the original code was improved a bit in other ways. A debugging example stanza was added in order to make the next debugging session simpler when the next bug is found.
-
- 22 Jul, 2016 2 commits
-
-
antirez authored
-
antirez authored
During the initial handshake with the master a slave will report to have a very high disconnection time from its master (since technically it was disconnected since forever, so the current UNIX time in seconds is reported). However when the slave is connected again the Sentinel may re-scan the INFO output again only after 10 seconds, which is a long time. During this time Sentinels will consider this instance unable to failover, so a useless delay is introduced. Actaully this hardly happened in the practice because when a slave's master is down, the INFO period for slaves changes to 1 second. However when a manual failover is attempted immediately after adding slaves (like in the case of the Sentinel unit test), this problem may happen. This commit changes the INFO period to 1 second even in the case the slave's master is not down, but the slave reported to be disconnected from the master (by publishing, last time we checked, a master disconnection time field in INFO). This change is required as a result of an unrelated change in the replication code that adds a small delay in the master-slave first synchronization.
-
- 06 Jul, 2016 1 commit
-
-
antirez authored
-
- 04 Jul, 2016 1 commit
-
-
antirez authored
-
- 28 Jun, 2016 3 commits
- 15 Jun, 2016 2 commits
- 05 Jun, 2016 1 commit
-
-
Pierre Chapuis authored
-
- 31 May, 2016 2 commits
- 18 May, 2016 1 commit
-
-
antirez authored
-