summaryrefslogtreecommitdiff
path: root/src/scripting.c
Commit message (Collapse)AuthorAgeFilesLines
* Scripting: ability to turn on Lua commands style replication globally.antirez2015-10-301-1/+1
| | | | | | 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.
* Scripting: fix error reporting of many Redis provided functions.antirez2015-10-301-14/+14
|
* Fix call() FORCE_REPL/AOF flags setting.antirez2015-10-301-13/+14
| | | | | This commit also inverts two stanzas of the code just becuase they are more logical like that, not because currently it makes any difference.
* Lua script selective replication fixes.antirez2015-10-301-5/+5
|
* Lua script selective replication WIP.antirez2015-10-301-2/+56
|
* Scripting: single commands replication mode implemented.antirez2015-10-301-7/+67
| | | | | | | | | | | | | | | | | 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.
* Lazyfree: client output buffers no longer use Redis Objects.antirez2015-10-011-2/+2
|
* RDMF: More consistent define names.antirez2015-07-271-29/+29
|
* RDMF: REDIS_OK REDIS_ERR -> C_OK C_ERR.antirez2015-07-261-11/+11
|
* RDMF: redisAssert -> serverAssert.antirez2015-07-261-3/+3
|
* RDMF: OBJ_ macros for object related stuff.antirez2015-07-261-2/+2
|
* RDMF: use client instead of redisClient, like Disque.antirez2015-07-261-7/+7
|
* RDMF: redisLog -> serverLog.antirez2015-07-261-4/+4
|
* RDMF (Redis/Disque merge friendlyness) refactoring WIP 1.antirez2015-07-261-1/+1
|
* Merge branch 'sds' into unstableantirez2015-07-241-8/+4
|\
| * sds size classes - memory optimizationOran Agra2015-07-141-8/+4
| |
* | config tcp-keepalive should be numerical field not boolJiahao Huang2015-07-161-1/+1
|/
* hide access to debug tableBen Murphy2015-06-031-6/+9
|
* Cluster: fix Lua scripts replication to slave nodes.antirez2015-03-221-2/+3
|
* luaRedisGenericCommand(): log error at WARNING level when re-entered.antirez2015-01-201-2/+5
| | | | | | | | Rationale is that when re-entering, it is likely due to Lua debugging hooks. Returning an error will be ignored in most cases, going totally unnoticed. With the log at least we leave a trace. Related to issue #2302.
* luaRedisGenericCommand() recursion: just return an error.antirez2015-01-201-1/+3
| | | | | | Instead of calling redisPanic() to abort the server. Related to issue #2302.
* Panic on recursive calls to luaRedisGenericCommand().antirez2015-01-201-0/+14
| | | | Related to issue #2302.
* Prevent Lua scripts from violating Redis Cluster keyspace access rules.antirez2015-01-091-1/+18
| | | | | Before this commit scripts were able to access / create keys outside the set of hash slots served by the local node.
* Lua: Add bitopMatt Stancliff2014-10-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | A few people have written custom C commands because bit manipulation isn't exposed through Lua. Let's give them Mike Pall's bitop. This adds bitop 1.0.2 (2012-05-08) from http://bitop.luajit.org/ bitop is imported as "bit" into the global namespace. New Lua commands: bit.tobit, bit.tohex, bit.bnot, bit.band, bit.bor, bit.bxor, bit.lshift, bit.rshift, bit.arshift, bit.rol, bit.ror, bit.bswap Verification of working (the asserts would abort on error, so (nil) is correct): 127.0.0.1:6379> eval "assert(bit.tobit(1) == 1); assert(bit.band(1) == 1); assert(bit.bxor(1,2) == 3); assert(bit.bor(1,2,4,8,16,32,64,128) == 255)" 0 (nil) 127.0.0.1:6379> eval 'assert(0x7fffffff == 2147483647, "broken hex literals"); assert(0xffffffff == -1 or 0xffffffff == 2^32-1, "broken hex literals"); assert(tostring(-1) == "-1", "broken tostring()"); assert(tostring(0xffffffff) == "-1" or tostring(0xffffffff) == "4294967295", "broken tostring()")' 0 (nil) Tests also integrated into the scripting tests and can be run with: ./runtest --single unit/scripting Tests are excerpted from `bittest.lua` included in the bitop distribution.
* Fix typo in scripting.c commentJuarez Bochi2014-09-291-1/+1
| | | | Closes #1960
* luaRedisGenericCommand() cached argv handling simplified.antirez2014-09-101-4/+2
| | | | As discussed in issue #1945.
* Store the length of the static argv when first allocated.Paddy Byers2014-09-011-0/+1
|
* Remove warnings and improve integer sign correctness.antirez2014-08-131-1/+1
|
* scripting: no eval with negative key countMatt Stancliff2014-08-071-0/+3
| | | | | | | Negative key count causes segfault in Lua functions. Fixes #1842 Closes #1843
* Fix semantics of Lua calls to SELECT.antirez2014-06-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Scripting: Fix for a #1118 regression simplified.antirez2014-06-111-6/+1
| | | | | | | | 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.
* Scripting: Fix regression from #1118Matt Stancliff2014-06-101-1/+6
| | | | | | | | | | | | | | 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.
* Fixed dbuf variable scope in luaRedisGenericCommand().antirez2014-06-041-1/+1
| | | | | | | 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.
* Scripting: better Lua number -> string conversion in luaRedisGenericCommand().antirez2014-06-041-4/+14
| | | | | | | | | | | | | | 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.
* Merge branch 'unstable' of github.com:/antirez/redis into unstableantirez2014-05-201-1/+3
|\
| * Fix LUA_OBJCACHE segfault.michael-grunder2014-05-191-1/+3
| | | | | | | | | | | | | | | | | | | | 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.
* | Remove trailing spaces from scripting.cantirez2014-05-201-3/+3
|/
* Scripting: objects caching for Lua c->argv creation.antirez2014-05-071-3/+40
| | | | | | 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.
* Scripting: Use faster API for Lua client c->argv creation.antirez2014-05-071-3/+6
| | | | | | | 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.
* Scripting: don't call lua_gc() after Lua script run.antirez2014-05-071-1/+17
| | | | | | | | Calling lua_gc() after every script execution is too expensive, and apparently does not make the execution smoother: the same peak latency was measured before and after the commit. This change accounts for scripts execution speedup in the order of 10%.
* Scripting: cache argv in luaRedisGenericCommand().antirez2014-05-071-4/+15
| | | | ~ 4% consistently measured speed improvement.
* Fixed missing c->bufpos reset in luaRedisGenericCommand().antirez2014-05-071-0/+1
| | | | | Bug introduced when adding a fast path to avoid copying the reply buffer for small replies that fit into the client static buffer.
* Scripting: replace tolower() with faster code in evalGenericCommand().antirez2014-05-071-1/+5
| | | | | | The function showed up consuming a non trivial amount of time in the profiler output. After this change benchmarking gives a 6% speed improvement that can be consistently measured.
* Scripting: luaRedisGenericCommand() fast path for buffer-only replies.antirez2014-05-071-7/+15
| | | | | | When the reply is only contained in the client static output buffer, use a fast path avoiding the dynamic allocation of an SDS string to concatenate the client reply objects.
* Scripting: simpler reply buffer creation in luaRedisGenericCommand().antirez2014-05-071-5/+2
| | | | | It if faster to just create the string with a single sdsnewlen() call. If c->bufpos is zero, the call will simply be like sdsemtpy().
* Process events with processEventsWhileBlocked() when blocked.antirez2014-04-241-2/+1
| | | | | | | | 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).
* Fix script cache bug in the scripting engine.antirez2014-02-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes a serious Lua scripting replication issue, described by Github issue #1549. The root cause of the problem is that scripts were put inside the script cache, assuming that slaves and AOF already contained it, even if the scripts sometimes produced no changes in the data set, and were not actaully propagated to AOF/slaves. Example: eval "if tonumber(KEYS[1]) > 0 then redis.call('incr', 'x') end" 1 0 Then: evalsha <sha1 step 1 script> 1 0 At this step sha1 of the script is added to the replication script cache (the script is marked as known to the slaves) and EVALSHA command is transformed to EVAL. However it is not dirty (there is no changes to db), so it is not propagated to the slaves. Then the script is called again: evalsha <sha1 step 1 script> 1 1 At this step master checks that the script already exists in the replication script cache and doesn't transform it to EVAL command. It is dirty and propagated to the slaves, but they fail to evaluate the script as they don't have it in the script cache. The fix is trivial and just uses the new API to force the propagation of the executed command regardless of the dirty state of the data set. Thank you to @minus-infinity on Github for finding the issue, understanding the root cause, and fixing it.
* Scripting: use mstime() and mstime_t for lua_time_start.antirez2014-02-031-2/+2
| | | | | | | server.lua_time_start is expressed in milliseconds. Use mstime_t instead of long long, and populate it with mstime() instead of ustime()/1000. Functionally identical but more natural.
* Fixed grammar: before H the article is a, not an.antirez2013-12-051-2/+2
|
* Fixed critical memory leak from EVAL.antirez2013-08-291-4/+9
| | | | | | | | | | | | | | | | Multiple missing calls to lua_pop prevented the error handler function pushed on the stack for lua_pcall() to be popped before returning, causing a memory leak in almost all the code paths of EVAL (both successful calls and calls returning errors). This caused two issues: Lua leaking memory (and this was very visible from INFO memory output, as the 'used_memory_lua' field reported an always increasing amount of memory used), and as a result slower and slower GC cycles resulting in all the CPU being used. Thanks to Tanguy Le Barzic for noticing something was wrong with his 2.8 slave, and for creating a testing EC2 environment where I was able to investigate the issue.
View Lorry Controller Status