- 10 May, 2016 1 commit
-
-
antirez authored
-
- 07 May, 2016 1 commit
-
-
antirez authored
Use the COMMAND output to fill with partial information the built-in help. This makes redis-cli able to at least complete commands that are exported by the Redis server it is connected to, but were not available in the help.h file when the redis-cli binary was compiled.
-
- 05 May, 2016 8 commits
-
-
antirez authored
-
antirez authored
-
Ruben Bridgewater authored
-
antirez authored
-
antirez authored
Thanks to @tushar2708 for the PR. I applied a slightly different fix. Thanks to @cespare for reporting. Close #3024 Close #3020
-
Chris Thunes authored
Fixes #2515.
-
- 04 May, 2016 5 commits
- 02 May, 2016 1 commit
-
-
antirez authored
This fixes issue #3043. Before this fix, after a complete resharding of a master slots to other nodes, the master remains empty and the slaves migrate away to other masters with non-zero nodes. However the old master now empty, is no longer considered a target for migration, because the system has no way to tell it had slaves in the past. This fix leaves the algorithm used in the past untouched, but adds a new rule. When a new or old master which is empty and without slaves, are assigend with their first slot, if other masters in the cluster have slaves, they are automatically considered to be targets for replicas migration.
-
- 25 Apr, 2016 6 commits
- 22 Apr, 2016 1 commit
-
-
therealbill authored
I've renamed maxmemoryToString to evictPolicyToString since that is more accurate (and easier to mentally connect with the correct data), as well as updated the function to user server.maxmemory_policy rather than server.maxmemory. Now with a default config it is actually returning the correct policy rather than volatile-lru.
-
- 18 Apr, 2016 1 commit
-
-
Damian Janowski authored
-
- 15 Apr, 2016 2 commits
- 14 Apr, 2016 2 commits
- 13 Apr, 2016 3 commits
- 04 Apr, 2016 3 commits
-
-
antirez authored
This fix was written by Anthony LaTorre. The old code mis-calculated the amount of time to wait till next event.
-
antirez authored
-
antirez authored
This fix was suggested by Anthony LaTorre, that provided also a good test case that was used to verify the fix. The problem with the old implementation is that, the time returned by a timer event (that is the time after it want to run again) is added to the event *start time*. So if the event takes, in order to run, more than the time it says it want to be scheduled again for running, an infinite loop is triggered.
-
- 30 Mar, 2016 2 commits
-
-
Ryosuke Hasebe authored
-
Ryosuke Hasebe authored
-
- 02 Mar, 2016 4 commits