- 19 Jan, 2013 5 commits
-
-
guiquanz authored
-
Salvatore Sanfilippo authored
redis-cli prompt bug fix
-
Salvatore Sanfilippo authored
redis-cli: always exit if connection fails.
-
Salvatore Sanfilippo authored
Fix an error reply for CLIENT command
-
bitterb authored
-
- 18 Jan, 2013 3 commits
-
-
Salvatore Sanfilippo authored
redis-cli --rdb fails if server sends a ping
-
Jan-Erik Rediger authored
This avoids unnecessary core dumps. Fixes antirez/redis#894
-
Nathan Parry authored
Redis pings slaves in "pre-synchronization stage" with newlines. (See https://github.com/antirez/redis/blob/2.6.9/src/replication.c#L814) However, redis-cli does not expect this - it sees the newline as the end of the bulk length line, and ends up returning 0 as bulk the length. This manifests as the following when running redis-cli: $ ./src/redis-cli --rdb some_file SYNC sent to master, writing 0 bytes to 'some_file' Transfer finished with success. With this commit, we just ignore leading newlines while reading the bulk length line. To reproduce the problem, load enough data into Redis so that the preparation of the RDB snapshot takes long enough for a ping to occur while redis-cli is waiting for the data.
-
- 17 Jan, 2013 1 commit
-
-
charsyam authored
-
- 16 Jan, 2013 1 commit
-
-
antirez authored
-
- 15 Jan, 2013 4 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
Sometimes it is much simpler to debug complex Redis installations if it is possible to assign clients a name that is displayed in the CLIENT LIST output. This is the case, for example, for "leaked" connections. The ability to provide a name to the client makes it quite trivial to understand what is the part of the code implementing the client not releasing the resources appropriately. Behavior: CLIENT SETNAME: set a name for the client, or remove the current name if an empty name is set. CLIENT GETNAME: get the current name, or a nil. CLIENT LIST: now displays the client name if any. Thanks to Mark Gravell for pushing this idea forward.
-
antirez authored
Issue #828 shows how Redis was not correctly undoing a non-blocking connection attempt with the previous master when the master was set to a new address using the SLAVEOF command. This was also a result of lack of refactoring, so now there is a function to cancel the non blocking handshake with the master. The new function is now used when SLAVEOF NO ONE is called or when SLAVEOF is used to set the master to a different address.
-
- 11 Jan, 2013 1 commit
-
-
antirez authored
-
- 10 Jan, 2013 3 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
1) The event handler was no restored after a timeout condition if the command was eventually executed with success. 2) The command was not converted to EVAL in case of errors in the middle of the execution. 3) Terrible duplication of code without any apparent reason.
-
- 03 Jan, 2013 2 commits
- 20 Dec, 2012 1 commit
-
-
antirez authored
The problem does not exist in the Redis server implementation of mstime() but is only limited to redis-cli and redis-benchmark. Thix fixes issue #839.
-
- 17 Dec, 2012 2 commits
- 14 Dec, 2012 1 commit
-
-
antirez authored
REDIS_HZ is the frequency our serverCron() function is called with. A more frequent call to this function results into less latency when the server is trying to handle very expansive background operations like mass expires of a lot of keys at the same time. Redis 2.4 used to have an HZ of 10. This was good enough with almost every setup, but the incremental key expiration algorithm was working a bit better under *extreme* pressure when HZ was set to 100 for Redis 2.6. However for most users a latency spike of 30 milliseconds when million of keys are expiring at the same time is acceptable, on the other hand a default HZ of 100 in Redis 2.6 was causing idle instances to use some CPU time compared to Redis 2.4. The CPU usage was in the order of 0.3% for an idle instance, however this is a shame as more energy is consumed by the server, if not important resources. This commit introduces HZ as a runtime parameter, that can be queried by INFO or CONFIG GET, and can be modified with CONFIG SET. At the same time the default frequency is set back to 10. In this way we default to a sane value of 10, but allows users to easily switch to values up to 500 for near real-time applications if needed and if they are willing to pay this small CPU usage penalty.
-
- 12 Dec, 2012 2 commits
-
-
Salvatore Sanfilippo authored
Define _XOPEN_SOURCE appropriately on NetBSD.
-
Patrick TJ McPhee authored
-
- 11 Dec, 2012 1 commit
-
-
antirez authored
Config.h performs endianess detection including OS-specific headers to define the endianess macros, or when this is not possible, checking the processor type via ifdefs. Sometimes when the OS-specific macro is included, only __BYTE_ORDER is defined, while BYTE_ORDER remains undefined. There is code at the end of config.h endianess detection in order to define the macros without the underscore, but it was not working correctly. This commit fixes endianess detection fixing Redis on Linux / PPC64 and possibly other systems.
-
- 03 Dec, 2012 4 commits
-
-
Salvatore Sanfilippo authored
Resolution for Issue #804 Add Default-Start and Default-Stop LSB tags for RedHat startup...
-
antirez authored
Refactoring performed after issue #801 resolution (see commit 2f87cf8b) introduced a memory leak that is fixed by this commit. I simply forgot to free the new allocated dictionary in the client structure trusting the output of "make test" on OSX. However due to changes in the "leaks" utility the test was no longer testing memory leaks. This problem was also fixed. Fortunately the CI test running at ci.redis.io spotted the bug in the valgrind run. The leak never ended into a stable release.
-
antirez authored
Due to changes in recent releases of osx leaks utility, the osx leak detection no longer worked. Now it is fixed in a way that should be backward compatible.
-
Brian J. McManus authored
Issue 804 Add Default-Start and Default-Stop LSB tags for RedHat startup and update-rc.d compatability.
-
- 02 Dec, 2012 3 commits
-
-
antirez authored
To store the keys we block for during a blocking pop operation, in the case the client is blocked for more data to arrive, we used a simple linear array of redis objects, in the blockingState structure: robj **keys; int count; However in order to fix issue #801 we also use a dictionary in order to avoid to end in the blocked clients queue for the same key multiple times with the same client. The dictionary was only temporary, just to avoid duplicates, but since we create / destroy it there is no point in doing this duplicated work, so this commit simply use a dictionary as the main structure to store the keys we are blocked for. So instead of the previous fields we now just have: dict *keys; This simplifies the code and reduces the work done by the server during a blocking POP operation.
-
antirez authored
-
antirez authored
Sending a command like: BLPOP foo foo foo foo 0 Resulted into a crash before this commit since the client ended being inserted in the waiting list for this key multiple times. This resulted into the function handleClientsBlockedOnLists() to fail because we have code like that: if (de) { list *clients = dictGetVal(de); int numclients = listLength(clients); while(numclients--) { listNode *clientnode = listFirst(clients); /* server clients here... */ } } The code to serve clients used to remove the served client from the waiting list, so if a client is blocking multiple times, eventually the call to listFirst() will return NULL or worse will access random memory since the list may no longer exist as it is removed by the function unblockClientWaitingData() if there are no more clients waiting for this list. To avoid making the rest of the implementation more complex, this commit modifies blockForKeys() so that a client will be put just a single time into the waiting list for a given key. Since it is Saturday, I hope this fixes issue #801.
-
- 30 Nov, 2012 3 commits
-
-
antirez authored
SDIFF used an algorithm that was O(N) where N is the total number of elements of all the sets involved in the operation. The algorithm worked like that: ALGORITHM 1: 1) For the first set, add all the members to an auxiliary set. 2) For all the other sets, remove all the members of the set from the auxiliary set. So it is an O(N) algorithm where N is the total number of elements in all the sets involved in the diff operation. Cristobal Viedma suggested to modify the algorithm to the following: ALGORITHM 2: 1) Iterate all the elements of the first set. 2) For every element, check if the element also exists in all the other remaining sets. 3) Add the element to the auxiliary set only if it does not exist in any of the other sets. The complexity of this algorithm on the worst case is O(N*M) where N is the size of the first set and M the total number of sets involved in the operation. However when there are elements in common, with this algorithm we stop the computation for a given element as long as we find a duplicated element into another set. I (antirez) added an additional step to algorithm 2 to make it faster, that is to sort the set to subtract from the biggest to the smallest, so that it is more likely to find a duplicate in a larger sets that are checked before the smaller ones. WHAT IS BETTER? None of course, for instance if the first set is much larger than the other sets the second algorithm does a lot more work compared to the first algorithm. Similarly if the first set is much smaller than the other sets, the original algorithm will less work. So this commit makes Redis able to guess the number of operations required by each algorithm, and select the best at runtime according to the input received. However, since the second algorithm has better constant times and can do less work if there are duplicated elements, an advantage is given to the second algorithm.
-
antirez authored
-
antirez authored
-
- 29 Nov, 2012 3 commits
-
-
antirez authored
-
antirez authored
The idea is to be able to identify a build in a unique way, so for instance after a bug report we can recognize that the build is the one of a popular Linux distribution and perform the debugging in the same environment.
-
antirez authored
1) We no longer test location by location, otherwise the CPU write cache completely makes our business useless. 2) We still need a memory test that operates in steps from the first to the last location in order to never hit the cache, but that is still able to retain the memory content. This was tested using a Linux box containing a bad memory module with a zingle bit error (always zero). So the final solution does has an error propagation step that is: 1) Invert bits at every location. 2) Swap adiacent locations. 3) Swap adiacent locations again. 4) Invert bits at every location. 5) Swap adiacent locations. 6) Swap adiacent locations again. Before and after these steps, and after step 4, a CRC64 checksum is computed. If the three CRC64 checksums don't match, a memory error was detected.
-