1. 03 Aug, 2017 2 commits
  2. 02 Aug, 2017 1 commit
  3. 28 Jul, 2017 1 commit
  4. 24 Jul, 2017 8 commits
  5. 23 Jul, 2017 2 commits
    • antirez's avatar
      Modules: don't crash when Lua calls a module blocking command. · 31404355
      antirez authored
      Lua scripting does not support calling blocking commands, however all
      the native Redis commands are flagged as "s" (no scripting flag), so
      this is not possible at all. With modules there is no such mechanism in
      order to flag a command as non callable by the Lua scripting engine,
      moreover we cannot trust the modules users from complying all the times:
      it is likely that modules will be released to have blocking commands
      without such commands being flagged correctly, even if we provide a way to
      signal this fact.
      
      This commit attempts to address the problem in a short term way, by
      detecting that a module is trying to block in the context of the Lua
      scripting engine client, and preventing to do this. The module will
      actually believe to block as usually, but what happens is that the Lua
      script receives an error immediately, and the background call is ignored
      by the Redis engine (if not for the cleanup callbacks, once it
      unblocks).
      
      Long term, the more likely solution, is to introduce a new call called
      RedisModule_GetClientFlags(), so that a command can detect if the caller
      is a Lua script, and return an error, or avoid blocking at all.
      
      Being the blocking API experimental right now, more work is needed in
      this regard in order to reach a level well blocking module commands and
      all the other Redis subsystems interact peacefully.
      
      Now the effect is like the following:
      
          127.0.0.1:6379> eval "redis.call('hello.block',1,5000)" 0
          (error) ERR Error running script (call to
          f_b5ba35ff97bc1ef23debc4d6e9fd802da187ed53): @user_script:1: ERR
          Blocking module command called from Lua script
      
      This commit fixes issue #4127 in the short term.
      31404355
    • antirez's avatar
      5bfdfbe1
  6. 20 Jul, 2017 3 commits
    • antirez's avatar
      Make representClusterNodeFlags() more robust. · a3778f3b
      antirez authored
      This function failed when an internal-only flag was set as an only flag
      in a node: the string was trimmed expecting a final comma before
      exiting the function, causing a crash. See issue #4142.
      Moreover generation of flags representation only needed at DEBUG log
      level was always performed: a waste of CPU time. This is fixed as well
      by this commit.
      a3778f3b
    • antirez's avatar
      Fix two bugs in moduleTypeLookupModuleByID(). · b1c2e1a1
      antirez authored
      The function cache was not working at all, and the function returned
      wrong values if there where two or more modules exporting native data
      types.
      
      See issue #4131 for more details.
      b1c2e1a1
    • Leon Chen's avatar
      fix return wrong value of clusterDelNodeSlots · 9e7a8c02
      Leon Chen authored
      9e7a8c02
  7. 18 Jul, 2017 1 commit
  8. 15 Jul, 2017 1 commit
  9. 14 Jul, 2017 6 commits
  10. 12 Jul, 2017 1 commit
    • antirez's avatar
      Fix replication of SLAVEOF inside transaction. · e74f0aa6
      antirez authored
      In Redis 4.0 replication, with the introduction of PSYNC2, masters and
      slaves replicate commands to cascading slaves and to the replication
      backlog itself in a different way compared to the past.
      
      Masters actually replicate the effects of client commands.
      Slaves just propagate what they receive from masters.
      
      This mechanism can cause problems when the configuration of an instance
      is changed from master to slave inside a transaction. For instance
      we could send to a master instance the following sequence:
      
          MULTI
          SLAVEOF 127.0.0.1 0
          EXEC
          SLAVEOF NO ONE
      
      Before the fixes in this commit, the MULTI command used to be propagated
      into the replication backlog, however after the SLAVEOF command the
      instance is a slave, so the EXEC implementation failed to also propagate
      the EXEC command. When the slaves of the above instance reconnected,
      they were incrementally synchronized just sending a "MULTI". This put
      the master client (in the slaves) into MULTI st...
      e74f0aa6
  11. 11 Jul, 2017 4 commits
  12. 10 Jul, 2017 5 commits
  13. 06 Jul, 2017 5 commits