1. 18 Jan, 2019 1 commit
  2. 15 Jan, 2019 1 commit
  3. 11 Jan, 2019 1 commit
  4. 10 Jan, 2019 1 commit
  5. 09 Jan, 2019 14 commits
  6. 11 Dec, 2018 1 commit
  7. 07 Dec, 2018 1 commit
  8. 04 Dec, 2018 1 commit
  9. 30 Oct, 2018 1 commit
    • antirez's avatar
      asyncCloseClientOnOutputBufferLimitReached(): don't free fake clients. · 0c875c77
      antirez authored
      Fake clients are used in special situations and are not linked to the
      normal clients list, freeing them will always result in Redis crashing
      in one way or the other.
      
      It's not common to send replies to fake clients, but we have one usage
      in the modules API. When a client is blocked, we associate to the
      blocked client object (that is safe to manipulate in a thread), a fake
      client that accumulates replies. So because of this bug there was
      the problem described in issue #5443.
      
      The fix was verified to work with the provided example module. To write
      a regression is very hard and unlikely to be triggered in the future.
      0c875c77
  10. 09 Oct, 2018 3 commits
  11. 11 Sep, 2018 2 commits
  12. 04 Sep, 2018 1 commit
  13. 03 Sep, 2018 4 commits
  14. 31 Aug, 2018 3 commits
    • antirez's avatar
      After slave Lua script leaves busy state, re-process the master buffer. · 7fa49391
      antirez authored
      Technically speaking we don't really need to put the master client in
      the clients that need to be processed, since in practice the PING
      commands from the master will take care, however it is conceptually more
      sane to do so.
      7fa49391
    • antirez's avatar
      While the slave is busy, just accumulate master input. · 9ab91b8c
      antirez authored
      Processing command from the master while the slave is in busy state is
      not correct, however we cannot, also, just reply -BUSY to the
      replication stream commands from the master. The correct solution is to
      stop processing data from the master, but just accumulate the stream
      into the buffers and resume the processing later.
      
      Related to #5297.
      9ab91b8c
    • zhaozhao.zz's avatar
      networking: fix unexpected negative or zero readlen · dce7cefb
      zhaozhao.zz authored
      To avoid copying buffers to create a large Redis Object which
      exceeding PROTO_IOBUF_LEN 32KB, we just read the remaining data
      we need, which may less than PROTO_IOBUF_LEN. But the remaining
      len may be zero, if the bulklen+2 equals sdslen(c->querybuf),
      in client pause context.
      
      For example:
      
      Time1:
      
      python
      >>> import os, socket
      >>> server="127.0.0.1"
      >>> port=6379
      >>> data1="*3\r\n$3\r\nset\r\n$1\r\na\r\n$33000\r\n"
      >>> data2="".join("x" for _ in range(33000)) + "\r\n"
      >>> data3="\n\n"
      >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
      >>> s.settimeout(10)
      >>> s.connect((server, port))
      >>> s.send(data1)
      28
      
      Time2:
      
      redis-cli client pause 10000
      
      Time3:
      
      >>> s.send(data2)
      33002
      >>> s.send(data3)
      2
      >>> s.send(data3)
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      socket.error: [Errno 104] Connection reset by peer
      
      To fix that, we should check if remaining is greater than zero.
      dce7cefb
  15. 23 Aug, 2018 1 commit
    • zhaozhao.zz's avatar
      networking: make setProtocolError simple and clear · f2ad89a3
      zhaozhao.zz authored
      Function setProtocolError just records proctocol error
      details in server log, set client as CLIENT_CLOSE_AFTER_REPLY.
      It doesn't care about querybuf sdsrange, because we
      will do it after procotol parsing.
      f2ad89a3
  16. 14 Aug, 2018 2 commits
  17. 13 Aug, 2018 1 commit
    • zhaozhao.zz's avatar
      pipeline: do not sdsrange querybuf unless all commands processed · 14c4ddb5
      zhaozhao.zz authored
      This is an optimization for processing pipeline, we discussed a
      problem in issue #5229: clients may be paused if we apply `CLIENT
      PAUSE` command, and then querybuf may grow too large, the cost of
      memmove in sdsrange after parsing a completed command will be
      horrible. The optimization is that parsing all commands in queyrbuf
      , after that we can just call sdsrange only once.
      14c4ddb5
  18. 18 Jul, 2018 1 commit