- 12 Feb, 2015 3 commits
-
-
antirez authored
Related to PR #2357.
-
antirez authored
Related to PR #2357.
-
Chris Lamb authored
Signed-off-by:
Chris Lamb <chris@chris-lamb.co.uk>
-
- 11 Feb, 2015 13 commits
-
-
antirez authored
-
antirez authored
Fixed by @oranagra, thank you.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
Avoid code repetition introduced with PR #2367, also fixes the return value to always return 0 if there is nothing more to rehash.
-
Sun He authored
-
antirez authored
This is very similar to the optimization applied to dictGetRandomKeys, but applied to the single key variant. Related to issue #2306.
-
antirez authored
Related to issue #2306.
-
antirez authored
We use the invariant that the original table ht[0] is never populated up to the index before the current rehashing index. Related to issue #2306.
-
antirez authored
Related to issue #2306.
-
antirez authored
Related to issue #2306.
-
antirez authored
Related to issue #2306.
-
- 10 Feb, 2015 8 commits
-
-
Charles Hooper authored
-
antirez authored
-
antirez authored
--stat mode already used to reconnect automatically if the server is no longer available. This is useful since this is an interactive mode used for debugging, however the same applies to --latency and --latency-dist modes, so now both use the reconnecting command execution as well. The reconnection code was modified to use basic VT100 escape sequences in order to play better with different kinds of output on the screen when the reconnection happens, and to hide the reconnection attempt output when finally the reconnection happens.
-
antirez authored
So far not able to find a color palette within the 256 colors which is not confusing. However I believe it is a possible task, so will try better later.
-
antirez authored
Still not happy with the result but low grays are hard to see in certain monitors with a non perfect gamma.
-
antirez authored
-
antirez authored
-
antirez authored
-
- 02 Feb, 2015 1 commit
-
-
mattcollier authored
Code was adding '\n' (line 521) to the end of NIL values exlusively making csv output inconsistent. Removed '\n'
-
- 30 Jan, 2015 3 commits
-
-
antirez authored
-
antirez authored
This improves PFAIL -> FAIL switch. Too late at this point in the RC releases to add proper PFAIL/FAIL separate dictionary to do this in a less randomized way. Tested in practice with experiments that this helps. PFAIL -> FAIL average with 20 nodes and node-timeout set to 5 seconds takes 2.5 seconds without this commit, 1 second with this commit.
-
antirez authored
-
- 29 Jan, 2015 5 commits
-
-
antirez authored
Otherwise we risk sending not initialized data to other nodes, that may contain anything. This was actually not possible only because the initialization of the buffer where the cluster packets header is created was larger than the 3 gossip sections we use, so the memory was already all filled with zeroes by the memset().
-
antirez authored
Otherwise we risk sending not initialized data to other nodes, that may contain anything. This was actually not possible only because the initialization of the buffer where the cluster packets header is created was larger than the 3 gossip sections we use, so the memory was already all filled with zeroes by the memset().
-
antirez authored
-
antirez authored
-
antirez authored
Otherwise it is impossible to receive the majority of failure reports in the node_timeout*2 window in larger clusters. Still with a 200 nodes cluster, 20 gossip sections are a very reasonable amount of bytes to send. A side effect of this change is also fater cluster nodes joins for large clusters, because the cluster layout makes less time to propagate.
-
- 22 Jan, 2015 7 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
On Darwin /dev/urandom depletes terribly fast. This is not an issue normally, but with Redis Cluster we generate a lot of unique IDs, for example during nodes handshakes. Our IDs need just to be unique without other strong crypto requirements, so this commit turns the function into something that gets a 20 bytes seed from /dev/urandom, and produces the rest of the output just using SHA1 in counter mode.
-
Matt Stancliff authored
Fixes valgrind error: 48 bytes in 1 blocks are definitely lost in loss record 196 of 373 at 0x4910D3: je_malloc (jemalloc.c:944) by 0x42807D: zmalloc (zmalloc.c:125) by 0x41FA0D: dictGetIterator (dict.c:543) by 0x41FA48: dictGetSafeIterator (dict.c:555) by 0x459B73: clusterHandleSlaveMigration (cluster.c:2776) by 0x45BF27: clusterCron (cluster.c:3123) by 0x423344: serverCron (redis.c:1239) by 0x41D6CD: aeProcessEvents (ae.c:311) by 0x41D8EA: aeMain (ae.c:455) by 0x41A84B: main (redis.c:3832)
-
Matt Stancliff authored
If array has N elements, we can't read +1 if we are already at N. Also, we need to move elements by their storage size in the array, not just by individual bytes.
-
Matt Stancliff authored
[maybe] Fixes valgrind errors: 32 bytes in 4 blocks are definitely lost in loss record 107 of 228 at 0x80EA447: je_malloc (jemalloc.c:944) by 0x806E59C: zrealloc (zmalloc.c:125) by 0x80A9AFC: clusterSetMaster (cluster.c:801) by 0x80AEDC9: clusterCommand (cluster.c:3994) by 0x80682A5: call (redis.c:2049) by 0x8068A20: processCommand (redis.c:2309) by 0x8076497: processInputBuffer (networking.c:1143) by 0x8073BAF: readQueryFromClient (networking.c:1208) by 0x8060E98: aeProcessEvents (ae.c:412) by 0x806123B: aeMain (ae.c:455) by 0x806C3DB: main (redis.c:3832) 64 bytes in 8 blocks are definitely lost in loss record 143 of 228 at 0x80EA447: je_malloc (jemalloc.c:944) by 0x806E59C: zrealloc (zmalloc.c:125) by 0x80AAB40: clusterProcessPacket (cluster.c:801) by 0x80A847F: clusterReadHandler (cluster.c:1975) by 0x30000FF: ??? 80 bytes in 10 blocks are definitely lost in loss record 148 of 228 at 0x80EA447: je_malloc (jemalloc.c:944) by 0x806E59C: zrealloc (zmalloc.c:125) by 0x80AAB40: clusterProcessPacket (cluster.c:801) by 0x80A847F: clusterReadHandler (cluster.c:1975) by 0x2FFFFFF: ???
-
Matt Stancliff authored
Fixes valgrind error: Syscall param write(buf) points to uninitialised byte(s) at 0x514C35D: ??? (syscall-template.S:81) by 0x456B81: clusterWriteHandler (cluster.c:1907) by 0x41D596: aeProcessEvents (ae.c:416) by 0x41D8EA: aeMain (ae.c:455) by 0x41A84B: main (redis.c:3832) Address 0x5f268e2 is 2,274 bytes inside a block of size 8,192 alloc'd at 0x4932D1: je_realloc (jemalloc.c:1297) by 0x428185: zrealloc (zmalloc.c:162) by 0x4269E0: sdsMakeRoomFor.part.0 (sds.c:142) by 0x426CD7: sdscatlen (sds.c:251) by 0x4579E7: clusterSendMessage (cluster.c:1995) by 0x45805A: clusterSendPing (cluster.c:2140) by 0x45BB03: clusterCron (cluster.c:2944) by 0x423344: serverCron (redis.c:1239) by 0x41D6CD: aeProcessEvents (ae.c:311) by 0x41D8EA: aeMain (ae.c:455) by 0x41A84B: main (redis.c:3832) Uninitialised value was created by a stack allocation at 0x457810: nodeUpdateAddressIfNeeded (cluster.c:1236)
-