- 28 Sep, 2012 1 commit
-
-
antirez authored
Lua arrays can't contain nil elements (see http://www.lua.org/pil/19.1.html for more information), so Lua scripts were not able to return a multi-bulk reply containing nil bulk elements inside. This commit introduces a special conversion: a table with just a "nilbulk" field set to a boolean value is converted by Redis as a nil bulk reply, but at the same time for Lua this type is not a "nil" so can be used inside Lua arrays. This type is also assigned to redis.NIL, so the following two forms are equivalent and will be able to return a nil bulk reply as second element of a three elements array: EVAL "return {1,redis.NIL,3}" 0 EVAL "return {1,{nilbulk=true},3}" 0 The result in redis-cli will be: 1) (integer) 1 2) (nil) 3) (integer) 3
-
- 04 Sep, 2012 1 commit
-
-
antirez authored
SORT is able to return (faster than when ordering) unordered output if the "BY" clause is used with a constant value. However we try to play well with scripting requirements of determinism providing always sorted outputs when SORT (and other similar commands) are called by Lua scripts. However we used the general mechanism in place in scripting in order to reorder SORT output, that is, if the command has the "S" flag set, the Lua scripting engine will take an additional step when converting a multi bulk reply to Lua value, calling a Lua sorting function. This is suboptimal as we can do it faster inside SORT itself. This is also broken as issue #545 shows us: basically when SORT is used with a constant BY, and additionally also GET is used, the Lua scripting engine was trying to order the output as a flat array, while it was actually a list of key-value pairs. What we do know is to recognized if the caller of SORT is the Lua client (since we can check this using the REDIS_LUA_CLIENT flag). If so, and if a "don't sort" condition is triggered by the BY option with a constant string, we force the lexicographical sorting. This commit fixes this bug and improves the performance, and at the same time simplifies the implementation. This does not mean I'm smart today, it means I was stupid when I committed the original implementation ;)
-
- 31 Aug, 2012 2 commits
-
-
antirez authored
Lua scripting uses a fake client in order to run commands in the context of a client, accumulate the reply, and convert it into a Lua object to return to the caller. This client is reused again and again, and is referenced by the server.lua_client globally accessible pointer. However after every call to redis.call() or redis.pcall(), that is handled by the luaRedisGenericCommand() function, the reply_bytes field of the client was not set back to zero. This filed is used to estimate the amount of memory currently used in the reply. Because of the lack of reset, script after script executed, this value used to get bigger and bigger, and in the end on 32 bit systems it triggered the following assert: redisAssert(c->reply_bytes < ULONG_MAX-(1024*64)); On 64 bit systems this does not happen because it takes too much time to reach values near to 2^64 for users to see the practical effect of the bug. Now in the cleanup stage of luaRedisGenericCommand() we reset the reply_bytes counter to zero, avoiding the issue. It is not practical to add a test for this bug, but the fix was manually tested using a debugger. This commit fixes issue #656.
-
antirez authored
Redis used to crash with a call like the following: EVAL "redis.call()" 0 Now the explicit check for at least one argument prevents the problem. This commit fixes issue #655.
-
- 27 Apr, 2012 1 commit
-
-
antirez authored
An user reported a crash with Redis scripting (see issue #480 on github), inspection of the kindly provided strack trace showed that server.lua_caller was probably set to NULL. The stack trace also slowed that the call to the hook was originating from a point where we just used to set/get a few global variables in the Lua state. What was happening is that we did not set the timeout hook selectively only when the user script was called. Now we set it more selectively, specifically only in the context of the lua_pcall() call, and make sure to remove the hook when the call returns. Otherwise the hook can get called in random contexts every time we do something with the Lua state.
-
- 23 Apr, 2012 1 commit
-
-
antirez authored
-
- 13 Apr, 2012 6 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
Lua global protection can now be simpified becuase we no longer have the global() function. It's useless to occupy memory with this table, it is also not faster because the metamethods we use are only called when a global object does not exist or we are trying to create it from a script.
-
antirez authored
After considering the interaction between ability to delcare globals in scripts using the 'global' function, and the complexities related to hanlding replication and AOF in a sane way with globals AND ability to turn protection On and Off, we reconsidered the design. The new design makes clear that there is only one good way to write Redis scripts, that is not using globals. In the rare cases state must be retained across calls a Redis key can be used.
-
antirez authored
-
antirez authored
-
- 29 Mar, 2012 1 commit
-
-
antirez authored
-
- 28 Mar, 2012 1 commit
-
-
Nathan Fritz authored
(The original implementation was modified by @antirez to conform Redis coding standards.)
-
- 20 Mar, 2012 1 commit
-
-
antirez authored
This commit introduces support for read only slaves via redis.conf and CONFIG GET/SET commands. Also various semantical fixes are implemented here: 1) MULTI/EXEC with only read commands now work where the server is into a state where writes (or commands increasing memory usage) are not allowed. Before this patch everything inside a transaction would fail in this conditions. 2) Scripts just calling read-only commands will work against read only slaves, when the server is out of memory, or when persistence is into an error condition. Before the patch EVAL always failed in this condition.
-
- 24 Feb, 2012 1 commit
-
-
antirez authored
-
- 13 Feb, 2012 1 commit
-
-
lsbardel authored
-
- 02 Feb, 2012 1 commit
-
-
antirez authored
Now Lua scripts dispatch Redis commands properly calling the call() function. In order to make this possible call() was improved with a new flags argument that controls how the Redis command is executed.
-
- 01 Feb, 2012 1 commit
-
-
antirez authored
SORT is now more deterministic: does not accept to compare by score items that have scores not representing a valid double. Also items with the same score are compared lexycographically. At the same time the scripting side introduced the ability to sort the output of SORT when sort uses the BY <constant> optimization, resulting in no specific ordering. Since in this case the user may use GET, and the result of GET can be null, converted into false as Lua data type, this commit also introduces the ability to sort Lua tables containining false, only if the first (faster) attempt at using just table.sort with a single argument fails.
-
- 31 Jan, 2012 1 commit
-
-
antirez authored
Order output of commands returning random arrays using table.sort when called from Lua, partially fixing issue #165. The issue is yet not completely fixed since we can't add the REDIS_CMD_SORT_FOR_SCRIPT flag in SORT currently, both because it may contain NULLs and because it is not cool to re-sort everything at every call when instead this should be sorted only if BY <constant> is used.
-
- 29 Jan, 2012 1 commit
-
-
Jakub Wieczorek authored
-
- 18 Nov, 2011 1 commit
-
-
antirez authored
New script timeout semantics and SCRIPT KILL implemented. SHUTDOWN NOSAVE and SHUTDOWN SAVE implemented.
-
- 27 Oct, 2011 1 commit
-
-
antirez authored
If a Lua script executes for more time than the max time specified in the configuration Redis will log a warning, and will start accepting queries (re-entering the event loop), returning -SLOWSCRIPT error for all the commands but SHUTDOWN that remains callable.
-
- 25 Oct, 2011 4 commits
- 24 Oct, 2011 1 commit
-
-
antirez authored
-
- 20 Oct, 2011 1 commit
-
-
antirez authored
Redis.call is now split into two variants of the same function. Redis.call will raise an error by default. Redis.pcall will return the error object instead.
-
- 19 Oct, 2011 1 commit
-
-
antirez authored
JSON support for Lua scripting, based on work from @lp, thanks!. We are using the good and fast cjson by Mark Pulford.
-
- 04 Oct, 2011 1 commit
-
-
antirez authored
-
- 27 Sep, 2011 3 commits
-
-
antirez authored
-
antirez authored
Return errors if a write command is called inside a Lua script after a random command was called. See https://github.com/antirez/redis/issues/95 for more information.
-
antirez authored
-
- 23 Sep, 2011 1 commit
-
-
antirez authored
Lua math.random and math.randomseed replaced with our own version based on redisSrand48(). Seed initialized to the same value at every EVAL/EVALSHA call.
-
- 13 Jul, 2011 1 commit
-
-
antirez authored
-
- 25 May, 2011 4 commits
-
-
antirez authored
Make sure error and status replies emitted by Lua scripts can never have more than a newline, otherwise it is a protocol violation and clients will desync.
-
antirez authored
-
antirez authored
All commands exported by Redis to Lua scripts are now inside the redis table. Implemented redis.log() function.
-
antirez authored
-