1. 11 Jun, 2014 2 commits
    • antirez's avatar
      Scripting: Fix for a #1118 regression simplified. · a3b0dbcc
      antirez authored
      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.
      a3b0dbcc
    • Matt Stancliff's avatar
      Scripting: Fix regression from #1118 · ba76daa4
      Matt Stancliff authored
      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.
      ba76daa4
  2. 09 Jun, 2014 3 commits
    • Matt Stancliff's avatar
      Fix lack of strtold under Cygwin · 8f774ee7
      Matt Stancliff authored
      Renaming strtold to strtod then casting
      the result is the standard way of dealing with
      no strtold in Cygwin.
      8f774ee7
    • Matt Stancliff's avatar
      Fix lack of SA_ONSTACK under Cygwin · 2af24143
      Matt Stancliff authored
      Fixes #232
      2af24143
    • Matt Stancliff's avatar
      Fix blocking operations from missing new lists · b4f9761d
      Matt Stancliff authored
      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
      b4f9761d
  3. 06 Jun, 2014 3 commits
  4. 05 Jun, 2014 2 commits
  5. 04 Jun, 2014 2 commits
    • antirez's avatar
      Fixed dbuf variable scope in luaRedisGenericCommand(). · 42504169
      antirez authored
      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.
      42504169
    • antirez's avatar
      Scripting: better Lua number -> string conversion in luaRedisGenericCommand(). · 768994b6
      antirez authored
      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.
      768994b6
  6. 28 May, 2014 1 commit
  7. 26 May, 2014 1 commit
  8. 22 May, 2014 3 commits
    • antirez's avatar
      Process events with processEventsWhileBlocked() when blocked. · f4823497
      antirez authored
      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).
      f4823497
    • antirez's avatar
      Accept multiple clients per iteration. · f3d3c606
      antirez authored
      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.
      f3d3c606
    • antirez's avatar
      41134739
  9. 20 May, 2014 3 commits
  10. 19 May, 2014 1 commit
  11. 14 May, 2014 1 commit
  12. 12 May, 2014 2 commits
  13. 09 May, 2014 1 commit
  14. 08 May, 2014 2 commits
    • antirez's avatar
      Sentinel: log when a failover will be attempted again. · 13d8b2b0
      antirez authored
      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
      13d8b2b0
    • antirez's avatar
      Sentinel: generate +config-update-from event when a new config is received. · 909d1883
      antirez authored
      This event makes clear, before the switch-master event is generated,
      that a Sentinel received a configuration update from another Sentinel.
      909d1883
  15. 07 May, 2014 9 commits
  16. 23 Apr, 2014 3 commits
  17. 22 Apr, 2014 1 commit