1. 28 Jan, 2020 2 commits
  2. 27 Jan, 2020 1 commit
  3. 15 Jan, 2020 2 commits
  4. 13 Jan, 2020 8 commits
  5. 10 Jan, 2020 7 commits
  6. 09 Jan, 2020 3 commits
  7. 08 Jan, 2020 6 commits
  8. 07 Jan, 2020 4 commits
  9. 06 Jan, 2020 1 commit
  10. 04 Jan, 2020 1 commit
  11. 01 Jan, 2020 2 commits
    • antirez's avatar
      Fix active expire division by zero. · 0af467d1
      antirez authored
      Likely fix #6723.
      
      This is what happens AFAIK: we enter the main loop where we expire stuff
      until a given percentage of keys is still found to be logically expired.
      There are however other potential exit conditions.
      
      However the "sampled" variable is not always incremented inside the
      loop, because we may found no valid slot as we scan the hash table, but
      just NULLs ad dict entries. So when the do/while loop condition is
      triggered at the end, we do (expired*100/sampled), dividing by zero if
      we sampled 0 keys.
      0af467d1
    • John Sully's avatar
      e5565a79
  12. 31 Dec, 2019 2 commits
    • ShooterIT's avatar
      Rename rdb asynchronously · 2bc8db9c
      ShooterIT authored
      2bc8db9c
    • WuYunlong's avatar
      Fix petential cluster link error. · 0992ada2
      WuYunlong authored
      Funcion adjustOpenFilesLimit() has an implicit parameter, which is server.maxclients.
      This function aims to ajust maximum file descriptor number according to server.maxclients
      by best effort, which is "bestlimit" could be lower than "maxfiles" but greater than "oldlimit".
      When we try to increase "maxclients" using CONFIG SET command, we could increase maximum
      file descriptor number to a bigger value without calling aeResizeSetSize the same time.
      When later more and more clients connect to server, the allocated fd could be bigger and bigger,
      and eventually exceeds events size of aeEventLoop.events. When new nodes joins the cluster,
      new link is created, together with new fd, but when calling aeCreateFileEvent, we did not
      check the return value. In this case, we have a non-null "link" but the associated fd is not
      registered.
      
      So when we dynamically set "maxclients" we could reach an inconsistency between maximum file
      descriptor number of the process and server.maxclients. And later could cause cluster link and link
      fd inconsistency.
      
      While setting "maxclients" dynamically, we consider it as failed when resulting "maxclients" is not
      the same as expected. We try to restore back the maximum file descriptor number when we failed to set
      "maxclients" to the specified value, so that server.maxclients could act as a guard as before.
      0992ada2
  13. 30 Dec, 2019 1 commit
    • Guy Benoish's avatar
      Blocking XREAD[GROUP] should always reply with valid data (or timeout) · a351e74f
      Guy Benoish authored
      This commit solves the following bug:
      127.0.0.1:6379> XGROUP CREATE x grp $ MKSTREAM
      OK
      127.0.0.1:6379> XADD x 666 f v
      "666-0"
      127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x >
      1) 1) "x"
         2) 1) 1) "666-0"
               2) 1) "f"
                  2) "v"
      127.0.0.1:6379> XADD x 667 f v
      "667-0"
      127.0.0.1:6379> XDEL x 667
      (integer) 1
      127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x >
      1) 1) "x"
         2) (empty array)
      
      The root cause is that we use s->last_id in streamCompareID
      while we should use the last *valid* ID
      a351e74f