- 08 Jan, 2016 1 commit
-
-
antirez authored
An exposed Redis instance on the internet can be cause of serious issues. Since Redis, by default, binds to all the interfaces, it is easy to forget an instance without any protection layer, for error. Protected mode try to address this feature in a soft way, providing a layer of protection, but giving clues to Redis users about why the server is not accepting connections. When protected mode is enabeld (the default), and if there are no minumum hints about the fact the server is properly configured (no "bind" directive is used in order to restrict the server to certain interfaces, nor a password is set), clients connecting from external intefaces are refused with an error explaining what to do in order to fix the issue. Clients connecting from the IPv4 and IPv6 lookback interfaces are still accepted normally, similarly Unix domain socket connections are not restricted in any way.
-
- 17 Dec, 2015 2 commits
-
-
antirez authored
In issue #2948 a crash was reported in processCommand(). Later Oran Agra (@oranagra) traced the bug (in private chat) in the following sequence of events: 1. Some maxmemory is set. 2. The slave is the currently active client and is executing PING or REPLCONF or whatever a slave can send to its master. 3. freeMemoryIfNeeded() is called since maxmemory is set. 4. flushSlavesOutputBuffers() is called by freeMemoryIfNeeded(). 5. During slaves buffers flush, a write error could be encoutered in writeToClient() or sendReplyToClient() depending on the version of Redis. This will trigger freeClient() against the currently active client, so a segmentation fault will likely happen in processCommand() immediately after the call to freeMemoryIfNeeded(). There are different possible fixes: 1. Add flags to writeToClient() (recent versions code base) so that we can ignore the write errors, and use this flag in flushSlavesOutputBuffers(). However this is not simple to do in older versions of Redis. 2. Use freeClientAsync() during write errors. This works but changes the current behavior of releasing clients ASAP when possible. Normally we write to clients during the normal event loop processing, in the writable client, where there is no active client, so no care must be taken. 3. The fix of this commit: to detect that the current client is no longer valid. This fix is a bit "ad-hoc", but works across all the versions and has the advantage of not changing the remaining behavior. Only alters what happens during this race condition, hopefully.
-
antirez authored
-
- 13 Dec, 2015 1 commit
-
-
antirez authored
-
- 27 Nov, 2015 1 commit
-
-
antirez authored
My guess was that wait3() with WNOHANG could never return -1 and an error. However issue #2897 may possibly indicate that this could happen under non clear conditions. While we try to understand this better, better to handle a return value of -1 explicitly, otherwise in the case a BGREWRITE is in progress but wait3() returns -1, the effect is to match the first branch of the if/else block since server.rdb_child_pid is -1, and call backgroundSaveDoneHandler() without a good reason, that will, in turn, crash the Redis server with an assertion.
-
- 19 Nov, 2015 3 commits
- 17 Nov, 2015 2 commits
-
-
antirez authored
Maybe there are legitimate use cases for MIGRATE inside Lua scripts, at least for now. When the command will be executed in an asynchronous fashion (planned) it is possible we'll no longer be able to permit it from within Lua scripts.
-
antirez authored
Thanks to Oran Agra (@oranagra) for reporting. Key extraction would not work otherwise and it does not make sense to take wrong data in the command table.
-
- 10 Nov, 2015 1 commit
-
-
antirez authored
-
- 09 Nov, 2015 2 commits
- 05 Nov, 2015 1 commit
-
-
antirez authored
-
- 30 Oct, 2015 6 commits
-
-
antirez authored
Currently this feature is only accessible via DEBUG for testing, since otherwise depending on the instance configuration a given script works or is broken, which is against the Redis philosophy.
-
antirez authored
This commit also inverts two stanzas of the code just becuase they are more logical like that, not because currently it makes any difference.
-
antirez authored
-
antirez authored
By calling redis.replicate_commands(), the scripting engine of Redis switches to commands replication instead of replicating whole scripts. This is useful when the script execution is costly but only results in a few writes performed to the dataset. Morover, in this mode, it is possible to call functions with side effects freely, since the script execution does not need to be deterministic: anyway we'll capture the outcome from the point of view of changes to the dataset. In this mode math.random() returns different sequences at every call. If redis.replicate_commnads() is not called before any other write, the command returns false and sticks to whole scripts replication instead.
-
antirez authored
-
antirez authored
-
- 15 Oct, 2015 2 commits
- 01 Oct, 2015 2 commits
- 29 Jul, 2015 1 commit
-
-
antirez authored
-
- 28 Jul, 2015 5 commits
- 27 Jul, 2015 2 commits
- 26 Jul, 2015 6 commits
- 17 Jul, 2015 1 commit
-
-
Tom Kiemes authored
aof_delayed_fsync was not set to 0 when calling CONFIG RESETSTAT
-
- 16 Jul, 2015 1 commit
-
-
antirez authored
The previos attempt to process each client at least once every ten seconds was not a good idea, because: 1. Usually because of the past min iterations set to 50, you get much better processing period most of the times. 2. However when there are many clients and a normal setting for server.hz, the edge case is triggered, and waiting 10 seconds for a BLPOP that asked for 1 second is not ok. 3. Moreover, because of the high min-itereations limit of 50, when HZ was set to an high value, the actual behavior was to process a lot of clients per second. Also the function checking for timeouts called gettimeofday() at each iteration which can be costly. The new implementation will try to process each client once per second, gets the current time as argument, and does not attempt to process more than 5 clients per iteration if not needed. So now: 1. The CPU usage of an idle Redis process is the same or better. 2. The CPU usage of a busy Redis process is the same or better. 3. However a non trivial amount of work may be performed per iteration when there are many many clients. In this particular case the user may want to raise the "HZ" value if needed. Btw with 4000 clients it was still not possible to noticy any actual latency created by processing 400 clients per second, since the work performed for each client is pretty small.
-