- 04 Jul, 2014 4 commits
- 02 Jul, 2014 14 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
This commit adds both support for redis.conf and CONFIG SET/GET.
-
antirez authored
-
antirez authored
-
- 01 Jul, 2014 8 commits
-
-
antirez authored
It is not a good idea to bloat the code with gettimeofday() calls if the instance is working well, and turning monitoring on at runtime is a joke.
-
antirez authored
-
antirez authored
Instead we update the old sample with the new latency if it is greater.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
We introduce the distinction between slow and fast commands since those are two different sources of latency. An O(1) or O(log N) command without side effects (can't trigger deletion of large objects as a side effect of its execution) if delayed is a symptom of inherent latency of the system. A non-fast command (commands that may run large O(N) computations) if delayed may just mean that the user is executing slow operations. The advices LATENCY should provide in this two different cases are different, so we log the two classes of commands in a separated way.
-
antirez authored
-
- 30 Jun, 2014 3 commits
- 27 Jun, 2014 6 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
This fixes detection of wrong subcommand (that resulted in the default all-commands output instead) and allows COMMAND INFO to be called without arguments (resulting into an empty array) which is useful in programmtically generated calls like the following (in Ruby): redis.commands("command","info",*mycommands) Note: mycommands may be empty.
-
antirez authored
-
antirez authored
Static was removed since it is needed in order to get symbols in stack traces. Minor changes in the source code were operated to make it more similar to the existing Redis code base.
-
Matt Stancliff authored
COMMANDS returns a nested multibulk reply for each command in the command table. The reply for each command contains: - command name - arity - array of command flags - start key position - end key position - key offset step - optional: if the keys are not deterministic and Redis uses an internal key evaluation function, the 6th field appears and is defined as a status reply of: REQUIRES ARGUMENT PARSING Cluster clients need to know where the keys are in each command to implement proper routing to cluster nodes. Redis commands can have multiple keys, keys at offset steps, or other issues where you can't always assume the first element after the command name is the cluster routing key. Using the information exposed by COMMANDS, client implementations can have live, accurate key extraction details for all commands. Also implements COMMANDS INFO [commands...] to return only a specific set of commands instead of all 160+ commands live in Redis.
-
- 26 Jun, 2014 5 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
Technically the problem is due to the client type API that does not return a special value for the master, however fixing it locally in the CLIENT KILL command is better currently because otherwise we would introduce a new output buffer limit class as a side effect.
-
antirez authored
Added for debugging and forgot there.
-
antirez authored
This is supposed to fix issue #1417, but we'll know if this is enough only after a couple of runs of the CI test without false positives.
-