- 30 Oct, 2013 4 commits
- 28 Oct, 2013 8 commits
-
-
antirez authored
-
antirez authored
Thanks to @badboy for reporting.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
Sorting the output helps when we want to turn a non-deterministic into a deterministic command, in that case this is not possible.
-
antirez authored
The new implementation is capable of iterating the keyspace but also sets, hashes, and sorted sets, and can be used to implement SSCAN, ZSCAN and HSCAN.
-
- 25 Oct, 2013 15 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
Pieter Noordhuis authored
The irrelevant bits shouldn't be masked to 1. This can result in slots being skipped when the hash table is resized between calls to the iterator.
-
Pieter Noordhuis authored
-
Pieter Noordhuis authored
-
- 11 Oct, 2013 2 commits
- 09 Oct, 2013 5 commits
-
-
antirez authored
-
antirez authored
After the change in clusterCron() frequency of call, we still want to ping just one random node every second.
-
antirez authored
-
antirez authored
All the internal state of cluster involving time is now using mstime_t and mstime() in order to use milliseconds resolution. Also the clusterCron() function is called with a 10 hz frequency instead of 1 hz. The cluster node_timeout must be also configured in milliseconds by the user in redis.conf.
-
antirez authored
-
- 08 Oct, 2013 2 commits
-
-
antirez authored
-
antirez authored
When a slave requests our vote, the configEpoch he claims for its master and the set of served slots must be greater or equal to the configEpoch of the nodes serving these slots in the current configuraiton of the master granting its vote. In other terms, masters don't vote for slaves having a stale configuration for the slots they want to serve.
-
- 07 Oct, 2013 3 commits
- 04 Oct, 2013 1 commit
-
-
antirez authored
Sometimes when we resurrect a cached master after a successful partial resynchronization attempt, there is pending data in the output buffers of the client structure representing the master (likely REPLCONF ACK commands). If we don't reinstall the write handler, it will never be installed again by addReply*() family functions as they'll assume that if there is already data pending, the write handler is already installed. This bug caused some slaves after a successful partial sync to never send REPLCONF ACK, and continuously being detected as timing out by the master, with a disconnection / reconnection loop.
-