1. 14 May, 2020 2 commits
    • Oran Agra's avatar
      fix redis 6.0 not freeing closed connections during loading. · 9da134cd
      Oran Agra authored
      This bug was introduced by a recent change in which readQueryFromClient
      is using freeClientAsync, and despite the fact that now
      freeClientsInAsyncFreeQueue is in beforeSleep, that's not enough since
      it's not called during loading in processEventsWhileBlocked.
      furthermore, afterSleep was called in that case but beforeSleep wasn't.
      
      This bug also caused slowness sine the level-triggered mode of epoll
      kept signaling these connections as readable causing us to keep doing
      connRead again and again for ll of these, which keep accumulating.
      
      now both before and after sleep are called, but not all of their actions
      are performed during loading, some are only reserved for the main loop.
      
      fixes issue #7215
      9da134cd
    • antirez's avatar
      Tracking: send eviction messages when evicting entries. · e3b5648d
      antirez authored
      A fix for #7249.
      e3b5648d
  2. 08 May, 2020 4 commits
  3. 30 Apr, 2020 2 commits
    • antirez's avatar
      Comment clearly why we moved some code in #6623. · 606134f9
      antirez authored
      606134f9
    • srzhao's avatar
      fix pipelined WAIT performance issue. · ee627bb6
      srzhao authored
      If client gets blocked again in `processUnblockedClients`, redis will not send
      `REPLCONF GETACK *` to slaves untill next eventloop, so the client will be
      blocked for 100ms by default(10hz) if no other file event fired.
      
      move server.get_ack_from_slaves sinppet after `processUnblockedClients`, so
      that both the first WAIT command that puts client in blocked context and the
      following WAIT command processed in processUnblockedClients would trigger
      redis-sever to send `REPLCONF GETACK *`, so that the eventloop would get
      `REPLCONG ACK <reploffset>` from slaves and unblocked ASAP.
      ee627bb6
  4. 28 Apr, 2020 4 commits
  5. 27 Apr, 2020 2 commits
  6. 24 Apr, 2020 1 commit
    • antirez's avatar
      LCS -> STRALGO LCS. · 3722f89f
      antirez authored
      STRALGO should be a container for mostly read-only string
      algorithms in Redis. The algorithms should have two main
      characteristics:
      
      1. They should be non trivial to compute, and often not part of
      programming language standard libraries.
      2. They should be fast enough that it is a good idea to have optimized C
      implementations.
      
      Next thing I would love to see? A small strings compression algorithm.
      3722f89f
  7. 17 Apr, 2020 1 commit
  8. 15 Apr, 2020 1 commit
  9. 07 Apr, 2020 5 commits
    • antirez's avatar
      Speedup INFO by counting client memory incrementally. · 35c64b89
      antirez authored
      Related to #5145.
      
      Design note: clients may change type when they turn into replicas or are
      moved into the Pub/Sub category and so forth. Moreover the recomputation
      of the bytes used is problematic for obvious reasons: it changes
      continuously, so as a conservative way to avoid accumulating errors,
      each client remembers the contribution it gave to the sum, and removes
      it when it is freed or before updating it with the new memory usage.
      35c64b89
    • antirez's avatar
      LCS: initial functionality implemented. · a518a9a7
      antirez authored
      a518a9a7
    • srzhao's avatar
      Check OOM at script start to get stable lua OOM state. · 026cc11b
      srzhao authored
      Checking OOM by `getMaxMemoryState` inside script might get different result
      with `freeMemoryIfNeededAndSafe` at script start, because lua stack and
      arguments also consume memory.
      
      This leads to memory `borderline` when memory grows near server.maxmemory:
      
      - `freeMemoryIfNeededAndSafe` at script start detects no OOM, no memory freed
      - `getMaxMemoryState` inside script detects OOM, script aborted
      
      We solve this 'borderline' issue by saving OOM state at script start to get
      stable lua OOM state.
      
      related to issue #6565 and #5250.
      026cc11b
    • Valentino Geron's avatar
    • Guy Benoish's avatar
      Stale replica should allow MULTI/EXEC · 240094c9
      Guy Benoish authored
      Example: Client uses a pipe to send the following to a
      stale replica:
      
      MULTI
      .. do something ...
      DISCARD
      
      The replica will reply the MUTLI with -MASTERDOWN and
      execute the rest of the commands... A client using a
      pipe might not be aware that MULTI failed until it's
      too late.
      
      I can't think of a reason why MULTI/EXEC/DISCARD should
      not be executed on stale replicas...
      
      Also, enable MULTI/EXEC/DISCARD during loading
      240094c9
  10. 31 Mar, 2020 13 commits
  11. 25 Mar, 2020 5 commits
    • antirez's avatar
      PSYNC2: meaningful offset implemented. · 5f72f696
      antirez authored
      A very commonly signaled operational problem with Redis master-replicas
      sets is that, once the master becomes unavailable for some reason,
      especially because of network problems, many times it wont be able to
      perform a partial resynchronization with the new master, once it rejoins
      the partition, for the following reason:
      
      1. The master becomes isolated, however it keeps sending PINGs to the
      replicas. Such PINGs will never be received since the link connection is
      actually already severed.
      2. On the other side, one of the replicas will turn into the new master,
      setting its secondary replication ID offset to the one of the last
      command received from the old master: this offset will not include the
      PINGs sent by the master once the link was already disconnected.
      3. When the master rejoins the partion and is turned into a replica, its
      offset will be too advanced because of the PINGs, so a PSYNC will fail,
      and a full synchronization will be required.
      
      Related to issue #7002 and other discussion we had in the past around
      this problem.
      5f72f696
    • antirez's avatar
      Explain why we allow transactions in -BUSY state. · 8caa2714
      antirez authored
      Related to #7022.
      8caa2714
    • Oran Agra's avatar
      MULTI/EXEC during LUA script timeout are messed up · e43cd831
      Oran Agra authored
      Redis refusing to run MULTI or EXEC during script timeout may cause partial
      transactions to run.
      
      1) if the client sends MULTI+commands+EXEC in pipeline without waiting for
      response, but these arrive to the shards partially while there's a busy script,
      and partially after it eventually finishes: we'll end up running only part of
      the transaction (since multi was ignored, and exec would fail).
      
      2) similar to the above if EXEC arrives during busy script, it'll be ignored and
      the client state remains in a transaction.
      
      the 3rd test which i added for a case where MULTI and EXEC are ok, and
      only the body arrives during busy script was already handled correctly
      since processCommand calls flagTransaction
      e43cd831
    • antirez's avatar
      8783304a
    • bodong.ybd's avatar
      b3e4abf0