- 21 6月, 2014 5 次提交
-
-
由 antirez 提交于
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.
-
由 antirez 提交于
This commit adds peer ID caching in the client structure plus an API change and the use of sdsMakeRoomFor() in order to improve the reallocation pattern to generate the CLIENT LIST output. Both the changes account for a very significant speedup.
-
由 antirez 提交于
-
由 antirez 提交于
This commit also fixes a bug in the implementation of sdscatfmt() resulting from stale references to the SDS string header after sdsMakeRoomFor() calls.
-
由 antirez 提交于
sdscatprintf() relies on printf() family libc functions and is sometimes too slow in critical code paths. sdscatfmt() is an alternative which is: 1) Far less capable. 2) Format specifier uncompatible. 3) Faster. It is suitable to be used in those speed critical code paths such as CLIENT LIST output generation.
-
- 19 6月, 2014 2 次提交
-
-
由 antirez 提交于
Eventual configuration convergence is guaranteed by our periodic hello messages to all the instances, however when there are important notices to share, better make a phone call. With this commit we force an hello message to other Sentinal and Redis instances within the next 100 milliseconds of a config update, which is practically better than waiting a few seconds.
-
由 antirez 提交于
Lack of check of the SRI_PROMOTED flag caused Sentienl to act with the promoted slave turned into a master during failover like if it was a normal instance. Normally this problem was not apparent because during real failovers the old master is down so the bugged code path was not entered, however with manual failovers via the SENTINEL FAILOVER command, the problem was easily triggered. This commit prevents promoted slaves from getting reconfigured, moreover we now explicitly check that during a failover the slave turning into a master is the one we selected for promotion and not a different one.
-
- 18 6月, 2014 2 次提交
-
-
由 Alex Suraci 提交于
-
由 Matt Stancliff 提交于
If we run a long latency session and want to Ctrl-C out of it, it's nice to still get the summary output at the end.
-
- 16 6月, 2014 1 次提交
-
-
由 antirez 提交于
Lua scripts are executed in the context of the currently selected database (as selected by the caller of the script). However Lua scripts are also free to use the SELECT command in order to affect other DBs. When SELECT is called frm Lua, the old behavior, before this commit, was to automatically set the Lua caller selected DB to the last DB selected by Lua. See for example the following sequence of commands: SELECT 0 SET x 10 EVAL "redis.call('select','1')" 0 SET x 20 Before this commit after the execution of this sequence of commands, we'll have x=10 in DB 0, and x=20 in DB 1. Because of the problem above, there was a bug affecting replication of Lua scripts, because of the actual implementation of replication. It was possible to fix the implementation of Lua scripts in order to fix the issue, but looking closely, the bug is the consequence of the behavior of Lua ability to set the caller's DB. Under the old semantics, a script selecting a different DB, has no simple ways to restore the state and select back the previously selected DB. Moreover the script auhtor must remember that the restore is needed, otherwise the new commands executed by the caller, will be executed in the context of a different DB. So this commit fixes both the replication issue, and this hard-to-use semantics, by removing the ability of Lua, after the script execution, to force the caller to switch to the DB selected by the Lua script. The new behavior of the previous sequence of commadns is to just set X=20 in DB 0. However Lua scripts are still capable of writing / reading from different DBs if needed. WARNING: This is a semantical change that will break programs that are conceived to select the client selected DB via Lua scripts. This fixes issue #1811.
-
- 11 6月, 2014 3 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
It is more straightforward to just test for a numerical type avoiding Lua's automatic conversion. The code is technically more correct now, however Lua should automatically convert to number only if the original type is a string that "looks like a number", and not from other types, so practically speaking the fix is identical AFAIK.
-
由 Matt Stancliff 提交于
The new check-for-number behavior of Lua arguments broke users who use large strings of just integers. The Lua number check would convert the string to a number, but that breaks user data because Lua numbers have limited precision compared to an arbitrarily precise number wrapped in a string. Regression fixed and new test added. Fixes #1118 again.
-
- 09 6月, 2014 3 次提交
-
-
由 Matt Stancliff 提交于
Renaming strtold to strtod then casting the result is the standard way of dealing with no strtold in Cygwin.
-
由 Matt Stancliff 提交于
Fixes #232
-
由 Matt Stancliff 提交于
Behrad Zari discovered [1] and Josiah reported [2]: if you block and wait for a list to exist, but the list creates from a non-push command, the blocked client never gets notified. This commit adds notification of blocked clients into the DB layer and away from individual commands. Lists can be created by [LR]PUSH, SORT..STORE, RENAME, MOVE, and RESTORE. Previously, blocked client notifications were only triggered by [LR]PUSH. Your client would never get notified if a list were created by SORT..STORE or RENAME or a RESTORE, etc. Blocked client notification now happens in one unified place: - dbAdd() triggers notification when adding a list to the DB Two new tests are added that fail prior to this commit. All test pass. Fixes #1668 [1]: https://groups.google.com/forum/#!topic/redis-db/k4oWfMkN1NU [2]: #1668
-
- 06 6月, 2014 3 次提交
-
-
由 Andy Grunwald 提交于
-
由 Jan-Erik Rediger 提交于
-
由 zionwu 提交于
-
- 05 6月, 2014 4 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Replication is totally broken when a slave has this option, since it stops accepting updates from masters. This fixes issue #1434.
-
由 antirez 提交于
I'm not sure if while the visibility is the inner block, the fact we point to 'dbuf' is a problem or not, probably the stack var isx guaranteed to live until the function returns. However obvious code is better anyway.
-
由 antirez 提交于
The lua_to*string() family of functions use a non optimal format specifier when converting integers to strings. This has both the problem of the number being converted in exponential notation, which we don't use as a Redis return value when floating point numbers are involed, and, moreover, there is a loss of precision since the default format specifier is not able to represent numbers that must be represented exactly in the IEEE 754 number mantissa. The new code handles it as a special case using a saner conversion. This fixes issue #1118.
-
- 28 5月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 26 5月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
If we are in the signal handler, we don't want to handle the signal again. In extreme cases, this can cause a stack overflow and segfault Redis. Fixes #1771
-
- 22 5月, 2014 3 次提交
-
-
由 antirez 提交于
When we are blocked and a few events a processed from time to time, it is smarter to call the event handler a few times in order to handle the accept, read, write, close cycle of a client in a single pass, otherwise there is too much latency added for clients to receive a reply while the server is busy in some way (for example during the DB loading).
-
由 antirez 提交于
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.
-
由 antirez 提交于
-
- 20 5月, 2014 3 次提交
-
-
由 michael-grunder 提交于
When scanning the argument list inside of a redis.call() invocation for pre-cached values, there was no check being done that the argument we were on was in fact within the bounds of the cache size. So if a redis.call() command was ever executed with more than 32 arguments (current cache size #define setting) redis-server could segfault.
-
由 antirez 提交于
-
由 antirez 提交于
-
- 19 5月, 2014 1 次提交
-
-
由 Mike Trinkala 提交于
Set the MSB as documented.
-
- 15 5月, 2014 1 次提交
-
-
由 antirez 提交于
No REDIS_ENCODING_EMBSTR in 2.8 internals.
-
- 12 5月, 2014 2 次提交
-
-
由 Akos Vandra 提交于
(Note: commit message modified by @antirez for clarity).
-
由 Akos Vandra 提交于
-
- 09 5月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 08 5月, 2014 2 次提交
-
-
由 antirez 提交于
When a Sentinel performs a failover (successful or not), or when a Sentinel votes for a different Sentinel trying to start a failover, it sets a min delay before it will try to get elected for a failover. While not strictly needed, because if multiple Sentinels will try to failover the same master at the same time, only one configuration will eventually win, this serialization is practically very useful. Normal failovers are cleaner: one Sentinel starts to failover, the others update their config when the Sentinel performing the failover is able to get the selected slave to move from the role of slave to the one of master. However currently this timeout was implicit, so users could see Sentinels not reacting, after a failed failover, for some time, without giving any feedback in the logs to the poor sysadmin waiting for clues. This commit makes Sentinels more verbose about the delay: when a master is down and a failover attempt is not performed because the delay has still not elaped, something like that will be logged: Next failover delay: I will not start a failover before Thu May 8 16:48:59 2014
-
由 antirez 提交于
This event makes clear, before the switch-master event is generated, that a Sentinel received a configuration update from another Sentinel.
-
- 07 5月, 2014 2 次提交
-
-
由 antirez 提交于
Reusing small objects when possible is a major speedup under certain conditions, since it is able to avoid the malloc/free pattern that otherwise is performed for every argument in the client command vector.
-
由 antirez 提交于
Replace the three calls to Lua API lua_tostring, lua_lua_strlen, and lua_isstring, with a single call to lua_tolstring. ~ 5% consistent speed gain measured.
-