- 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 1 commit
-
-
antirez authored
-
- 23 Jun, 2014 1 commit
-
-
Matt Stancliff authored
Fixes #1826 (and many other reports of the same problem)
-
- 21 Jun, 2014 2 commits
-
-
Matt Stancliff authored
Fixes #1826 (and many other reports of the same problem)
-
antirez authored
-
- 16 Jun, 2014 2 commits
-
-
antirez authored
This will be used by CLIENT KILL and is also a good way to ensure a given client is still the same across CLIENT LIST calls. The output of CLIENT LIST was modified to include the new ID, but this change is considered to be backward compatible as the API does not imply you can do positional parsing, since each filed as a different name.
-
antirez authored
Because of output buffer limits Redis internals had this idea of type of clients: normal, pubsub, slave. It is possible to set different output buffer limits for the three kinds of clients. However all the macros and API were named after output buffer limit classes, while the idea of a client type is a generic one that can be reused. This commit does two things: 1) Rename the API and defines with more general names. 2) Change the class of clients executing the MONITOR command from "slave" to "normal". "2" is a good idea because you want to have very special settings for slaves, that are not a good idea for MONITOR clients that are instead normal clients even if they are conceptually slave-alike (since it is a push protocol). The backward-compatibility breakage resulting from "2" is considered to be minimal to care, since MONITOR is a debugging command, and because anyway this change is not going to break the format or the behavior, but just when a connection is closed on big output buffer issues.
-
- 07 Jun, 2014 1 commit
-
-
antirez authored
The new ROLE command is designed in order to provide a client with informations about the replication in a fast and easy to use way compared to the INFO command where the same information is also available.
-
- 05 Jun, 2014 1 commit
-
-
antirez authored
Replication is totally broken when a slave has this option, since it stops accepting updates from masters. This fixes issue #1434.
-
- 22 May, 2014 3 commits
- 12 May, 2014 1 commit
-
-
antirez authored
The error when the target key is busy was a generic one, while it makes sense to be able to distinguish between the target key busy error and the others easily.
-
- 24 Apr, 2014 1 commit
-
-
antirez authored
When the listening sockets readable event is fired, we have the chance to accept multiple clients instead of accepting a single one. This makes Redis more responsive when there is a mass-connect event (for example after the server startup), and in workloads where a connect-disconnect pattern is used often, so that multiple clients are waiting to be accepted continuously. As a side effect, this commit makes the LOADING, BUSY, and similar errors much faster to deliver to the client, making Redis more responsive when there is to return errors to inform the clients that the server is blocked in an not interruptible operation.
-
- 17 Apr, 2014 2 commits
- 16 Apr, 2014 1 commit
-
-
antirez authored
Like ZCOUNT for lexicographical ranges.
-
- 15 Apr, 2014 1 commit
-
-
antirez authored
-
- 14 Apr, 2014 1 commit
-
-
antirez authored
It is safer since it is able to have side effects.
-
- 13 Apr, 2014 1 commit
-
-
antirez authored
PFDEBUG will be the interface to do debugging tasks with a key containing an HLL object.
-
- 07 Apr, 2014 1 commit
-
-
antirez authored
adjustOpenFilesLimit() and clusterUpdateSlotsWithConfig() that were assuming uint64_t is the same as unsigned long long, which is true probably for all the systems out there that we target, but still GCC emitted a warning since technically they are two different types.
-
- 05 Apr, 2014 1 commit
-
-
antirez authored
-
- 03 Apr, 2014 1 commit
-
-
antirez authored
The new command allows to get a dump of the registers stored into an HyperLogLog data structure for testing / debugging purposes.
-
- 31 Mar, 2014 3 commits
- 28 Mar, 2014 3 commits
- 25 Mar, 2014 2 commits
-
-
antirez authored
Bug found by the continuous integration test running the Redis with valgrind: ==6245== Invalid read of size 8 ==6245== at 0x4C2DEEF: memcpy@GLIBC_2.2.5 (mc_replace_strmem.c:876) ==6245== by 0x41F9E6: freeMemoryIfNeeded (redis.c:3010) ==6245== by 0x41D2CC: processCommand (redis.c:2069) memmove() size argument was accounting for an extra element, going outside the bounds of the array.
-
antirez authored
In this commit: * Decrement steps are semantically differentiated from the reserved FDs. Previously both values were 32 but the meaning was different. * Make it clear that we save setrlimit errno. * Don't explicitly handle wrapping of 'f', but prevent it from happening. * Add comments to make the function flow more readable. This integrates PR #1630
-
- 24 Mar, 2014 4 commits
-
-
Matt Stancliff authored
errno may be reset by the previous call to redisLog, so capture the original value for proper error reporting.
-
Matt Stancliff authored
Also update the original REDIS_EVENTLOOP_FDSET_INCR to include REDIS_MIN_RESERVED_FDS. REDIS_EVENTLOOP_FDSET_INCR exists to make sure more than (maxclients+RESERVED) entries are allocated, but we can only guarantee that if we include the current value of REDIS_MIN_RESERVED_FDS as a minimum for the INCR size.
-
Matt Stancliff authored
Fun fact: rlim_t is an unsigned long long on all platforms. Continually subtracting from a rlim_t makes it get smaller and smaller until it wraps, then you're up to 2^64-1. This was causing an infinite loop on Redis startup if your ulimit was extremely (almost comically) low. The case of (f > oldlimit) would never be met in a case like: f = 150 while (f > 20) f -= 128 Since f is unsigned, it can't go negative and would take on values of: Iteration 1: 150 - 128 => 22 Iteration 2: 22 - 128 => 18446744073709551510 Iterations 3-∞: ... To catch the wraparound, we use the previous value of f stored in limit.rlimit_cur. If we subtract from f and get a larger number than the value it had previously, we print an error and exit since we don't have enough file descriptors to help the user at this point. Thanks to @bs3g for the inspiration to fix this problem. Patches existed from @bs3g at antirez#1227, but I needed to repair a few other parts of Redis simultaneously, so I didn't get a chance to use them.
-
Matt Stancliff authored
The log messages about open file limits have always been slightly opaque and confusing. Here's an attempt to fix their wording, detail, and meaning. Users will have a better understanding of how to fix very common problems with these reworded messages. Also, we handle a new error case when maxclients becomes less than one, essentially rendering the server unusable. We now exit on startup instead of leaving the user with a server unable to handle any connections. This fixes antirez#356 as well.
-