- 21 Jan, 2013 7 commits
-
-
antirez authored
-
antirez authored
UNSUBSCRIBE and PUNSUBSCRIBE commands are designed to mass-unsubscribe the client respectively all the channels and patters if called without arguments. However when these functions are called without arguments, but there are no channels or patters we are subscribed to, the old behavior was to don't reply at all. This behavior is broken, as every command should always reply. Also it is possible that we are no longer subscribed to a channels but we are subscribed to patters or the other way around, and the client should be notified with the correct number of subscriptions. Also it is not pretty that sometimes we did not receive a reply at all in a redis-cli session from these commands, blocking redis-cli trying to read the reply. This fixes issue #714.
-
antirez authored
This closes issue #859, thanks to @erbenmo.
-
Salvatore Sanfilippo authored
s/adiacent/adjacent/
-
Salvatore Sanfilippo authored
fixed some typos in Redis.c
-
Salvatore Sanfilippo authored
Typo in sentinel.conf
-
antirez authored
I don't know how to test for Open Solaris that has support for backtrace() so for now removing the #ifdef that breaks compilation under other Solaris flavors.
-
- 19 Jan, 2013 9 commits
-
-
antirez authored
-
antirez authored
This commit fixes issue #875 that was caused by the following events: 1) There is an active child doing BGSAVE. 2) flushall is called (or any other condition that makes Redis killing the saving child process). 3) An error is sensed by Redis as the child exited with an error (killed by a singal), that stops accepting write commands until a BGSAVE happens to be executed with success. Whitelisting SIGUSR1 and making sure Redis always uses this signal in order to kill its own children fixes the issue.
-
antirez authored
When a SIGTERM is received Redis schedules a shutdown. However if it fails to perform the shutdown it must be clear the shutdown_asap flag otehrwise it will try again and again possibly making the server unusable.
-
antirez authored
The Redis Slow Log always used to log the slow commands executed inside a MULTI/EXEC block. However also EXEC was logged at the end, which is perfectly useless. Now EXEC is no longer logged and a test was added to test this behavior. This fixes issue #759.
-
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 3 commits
-
-
antirez authored
-
Alice Kærast authored
Fixes a minor typo in sentinel.conf
-
Hu Weiwei 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.
-
- 09 Jan, 2013 1 commit
-
-
Bilal Husain authored
fixed typo in a comment (step 2 memcheck)
-
- 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
-