1. 21 Mar, 2014 2 commits
    • antirez's avatar
      Sentinel failure detection implementation improved. · 42091a79
      antirez authored
      Failure detection in Sentinel is ping-pong based. It used to work by
      remembering the last time a valid PONG reply was received, and checking
      if the reception time was too old compared to the current current time.
      
      PINGs were sent at a fixed interval of 1 second.
      
      This works in a decent way, but does not scale well when we want to set
      very small values of "down-after-milliseconds" (this is the node
      timeout basically).
      
      This commit reiplements the failure detection making a number of
      changes. Some changes are inspired to Redis Cluster failure detection
      code:
      
      * A new last_ping_time field is added in representation of instances.
        If non zero, we have an active ping that was sent at the specified
        time. When a valid reply to ping is received, the field is zeroed
        again.
      * last_ping_time is not reset when we reconnect the link or send a new
        ping, so from our point of view it represents the time we started
        waiting for the instance to reply to our pings without receiving a
        reply.
      * last_ping_time is now used in order to check if the instance is
        timed out. This means that we can have a node timeout of 100
        milliseconds and yet the system will work well since the new check is
        not bound to the period used to send pings.
      * Pings are now sent every second, or often if the value of
        down-after-milliseconds is less than one second. With a lower limit of
        10 HZ ping frequency.
      * Link reconnection code was improved. This is used in order to try to
        reconnect the link when we are at 50% of the node timeout without a
        valid reply received yet. However the old code triggered unnecessary
        reconnections when the node timeout was very small. Now that should be
        ok.
      
      The new code passes the tests but more testing is needed and more unit
      tests stressing the failure detector, so currently this is merged only
      in the unstable branch.
      42091a79
    • antirez's avatar
      Sentinel: use CLIENT SETNAME when connecting to Redis. · 38241c4b
      antirez authored
      This makes debugging / monitoring of Sentinels simpler since you can
      identify sentinels in CLIENT LIST output of Redis instances.
      38241c4b
  2. 14 Mar, 2014 4 commits
    • Matt Stancliff's avatar
      Fix segfault from accessing array out of bounds · 9de07558
      Matt Stancliff authored
      argc == 2; argv[2] == crash
      9de07558
    • antirez's avatar
      Sentinel: be safe under crash-recovery assumptions. · a31a0b43
      antirez authored
      Sentinel's main safety argument is that there are no two configurations
      for the same master with the same version (configuration epoch).
      
      For this to be true Sentinels require to be authorized by a majority.
      Additionally Sentinels require to do two important things:
      
      * Never vote again for the same epoch.
      * Never exchange an old vote for a fresh one.
      
      The first prerequisite, in a crash-recovery system model, requires to
      persist the master->leader_epoch on durable storage before to reply to
      messages. This was not the case.
      
      We also make sure to persist the current epoch in order to never reply
      to stale votes requests from other Sentinels, after a recovery.
      
      The configuration is persisted by making use of fsync(), this is
      considered in the context of this code a good enough guarantee that
      after a restart our durable state is restored, however this may not
      always be the case depending on the kind of hardware and operating
      system used.
      a31a0b43
    • antirez's avatar
      Sentinel: fake PUBLISH command to receive HELLO messages. · 6b0e36ff
      antirez authored
      Now the way HELLO messages are received is unified.
      Now it is no longer needed for Sentinels to converge to the higher
      configuration for a master to be able to chat via some Redis instance,
      the are able to directly exchanges configurations.
      
      Note that this commit does not include the (trivial) change needed to
      send HELLO messages to Sentinel instances as well, since for an error I
      committed the change in the previous commit that refactored hello
      messages processing into a separated function.
      6b0e36ff
    • antirez's avatar
  3. 13 Mar, 2014 1 commit
  4. 11 Mar, 2014 5 commits
  5. 10 Mar, 2014 3 commits
    • antirez's avatar
      DEBUG ERROR implemented. · eb9e1526
      antirez authored
      The new "error" subcommand of the DEBUG command can reply with an user
      selected error, specified as its sole argument:
      
          DEBUG ERROR "LOADING please wait..."
      
      The error is generated just prefixing the command argument with a "-"
      character, and replacing newlines with spaces (since error replies can't
      include newlines).
      
      The goal of the command is to help in Client libraries unit tests by
      making simple to simulate a command call triggering a given error.
      eb9e1526
    • Matt Stancliff's avatar
      Fix return value check for anetTcpAccept · a6970570
      Matt Stancliff authored
      anetTcpAccept returns ANET_ERR, not AE_ERR.
      
      This isn't a physical error since both ANET_ERR
      and AE_ERR are -1, but better to be consistent.
      a6970570
    • antirez's avatar
  6. 05 Mar, 2014 20 commits
  7. 28 Feb, 2014 1 commit
  8. 27 Feb, 2014 4 commits
    • antirez's avatar
      BITPOS fuzzy testing. · 950cb76e
      antirez authored
      950cb76e
    • antirez's avatar
      Basic BITPOS tests. · 42e3630d
      antirez authored
      42e3630d
    • antirez's avatar
      warnigns -> warnings in redisBitpos(). · 1892b562
      antirez authored
      1892b562
    • antirez's avatar
      More consistent BITPOS behavior with bit=0 and ranges. · 2c8036f7
      antirez authored
      With the new behavior it is possible to specify just the start in the
      range (the end will be assumed to be the first byte), or it is possible
      to specify both start and end.
      
      This is useful to change the behavior of the command when looking for
      zeros inside a string.
      
      1) If the user specifies both start and end, and no 0 is found inside
         the range, the command returns -1.
      
      2) If instead no range is specified, or just the start is given, even
         if in the actual string no 0 bit is found, the command returns the
         first bit on the right after the end of the string.
      
      So for example if the string stored at key foo is "\xff\xff":
      
          BITPOS foo (returns 16)
          BITPOS foo 0 -1 (returns -1)
          BITPOS foo 0 (returns 16)
      
      The idea is that when no end is given the user is just looking for the
      first bit that is zero and can be set to 1 with SETBIT, as it is
      "available". Instead when a specific range is given, we just look for a
      zero within the boundaries of the range.
      2c8036f7