- 18 Jan, 2019 1 commit
-
-
antirez authored
-
- 15 Jan, 2019 1 commit
-
-
antirez authored
-
- 11 Jan, 2019 1 commit
-
-
antirez authored
-
- 10 Jan, 2019 1 commit
-
-
antirez authored
-
- 09 Jan, 2019 14 commits
-
-
antirez authored
-
antirez authored
The function naming was totally nuts. Let's fix it as we break PRs anyway with RESP3 refactoring and changes.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 11 Dec, 2018 1 commit
-
-
antirez authored
See #5663.
-
- 07 Dec, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 04 Dec, 2018 1 commit
-
-
Madelyn Olson authored
-
- 30 Oct, 2018 1 commit
-
-
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.
-
- 09 Oct, 2018 3 commits
-
-
zhaozhao.zz authored
-
antirez authored
Related to #4840. Note that when we re-enter the event loop with aeProcessEvents() we don't process timers, nor before/after sleep callbacks, so we should never end calling freeClientsInAsyncFreeQueue() when re-entering the loop.
-
antirez authored
The idea is to have an API for the cases like -BUSY state and DEBUG RELOAD where we have to manually deinstall the read handler. See #4804.
-
- 11 Sep, 2018 2 commits
- 04 Sep, 2018 1 commit
-
-
antirez authored
See #5304.
-
- 03 Sep, 2018 4 commits
-
-
antirez authored
-
antirez authored
Related to #5305.
-
zhaozhao.zz authored
If we are going to read a large object from network try to make it likely that it will start at c->querybuf boundary so that we can optimize object creation avoiding a large copy of data. But only when the data we have not parsed is less than or equal to ll+2. If the data length is greater than ll+2, trimming querybuf is just a waste of time, because at this time the querybuf contains not only our bulk. It's easy to reproduce the that: Time1: call `client pause 10000` on slave. Time2: redis-benchmark -t set -r 10000 -d 33000 -n 10000. Then slave hung after 10 seconds.
-
zhaozhao.zz authored
-
- 31 Aug, 2018 3 commits
-
-
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.
-
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.
-
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.
-
- 23 Aug, 2018 1 commit
-
-
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.
-
- 14 Aug, 2018 2 commits
-
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
- 13 Aug, 2018 1 commit
-
-
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.
-
- 18 Jul, 2018 1 commit
-
-
antirez authored
See #5135 for more context.
-